Mailing List Archive

> Inspired by the XMLTV validation tester [1], I've repurposed the code
> [2] and put together a tool to monitor the status of all translations
> in MythTV trunk, by revision, language and component. The design is
> simple and mostly borrowed from the XMLTV tester, but I hope it
> conveys the important information clearly:

That's really nice, I was going to setup something like this, but you
beat me to it :)

Would it be possible to add the latest -fixes branch to the status
page? IMHO that would say much more about the status of the language,
since it doesn't really make that much sense to update a language in
trunk, until the themestrings are updated just prior to release of a
new MythTV version.

Take the Danish translation as an example: According to the trunk
status page, only 88% is translated in trunk (giving it an orange
color - a bit like a warning). That's really not because we're lacking
behind, it's just because we don't send any translations before the
themestrings are updated in SVN, which should happen somewhere around
the feature freeze. If you make the same statistics on the latest
stable version, you should get 100% (or perhaps 99% if a string or two
have been changed since the 0.23 release).

Another thing, do you generate new themestrings every time you
generate new statistics for trunk? If not, the current statistics only
shows half the truth.

I would probably generate the new themestrings on each trunk status
generation but just leave it out for each -fixes status generation, as
it doesn't/shouldn't change any more after release.

Best Regards
Kenni

On 19 August 2010 17:08, Kenni Lund <kenni at kelu.dk> wrote:
>> Inspired by the XMLTV validation tester [1], I've repurposed the code
>> [2] and put together a tool to monitor the status of all translations
>> in MythTV trunk, by revision, language and component. The design is
>> simple and mostly borrowed from the XMLTV tester, but I hope it
>> conveys the important information clearly:
>
> That's really nice, I was going to setup something like this, but you
> beat me to it :)
>
> Would it be possible to add the latest -fixes branch to the status
> page? IMHO that would say much more about the status of the language,
> since it doesn't really make that much sense to update a language in
> trunk, until the themestrings are updated just prior to release of a
> new MythTV version.

Certainly possible, and a very sensible idea. I might add the -fixes
to a separate set of status pages to keep trunk and previous fixes
branches separate (would make maintenance a lot easier).

Coincidentally, the themestrings have /just/ been updated, and you can
see the marked drop-off in the overall % numbers on the status page.

> Take the Danish translation as an example: According to the trunk
> status page, only 88% is translated in trunk (giving it an orange
> color - a bit like a warning). That's really not because we're lacking
> behind, it's just because we don't send any translations before the
> themestrings are updated in SVN, which should happen somewhere around
> the feature freeze. If you make the same statistics on the latest
> stable version, you should get 100% (or perhaps 99% if a string or two
> have been changed since the 0.23 release).

I will try and get this done in the next week.

> Another thing, do you generate new themestrings every time you
> generate new statistics for trunk? If not, the current statistics only
> shows half the truth.

The status updates are currently using an uncompiled source checkout,
so themestringstool is not run (only lupdate). This can be changed in
the script.

> I would probably generate the new themestrings on each trunk status
> generation but just leave it out for each -fixes status generation, as
> it doesn't/shouldn't change any more after release.

Perhaps it might be a good idea to update the status less (~1
update/month?) during the development cycle (release -> release +5
months) and then update perhaps once or twice a week once the code is
frozen and translations start to be submitted and applied? I notice
from 0.23-fixes that translations are backported after release, so it
seems sensible to continue to track the -fixes branch up until the
next version becomes frozen and all efforts go into that.

Many thanks for your (and Nick's) very useful feedback,
Nick

--
Nick Morrott

MythTV Official wiki: http://mythtv.org/wiki/
MythTV users list archive: http://www.gossamer-threads.com/lists/mythtv/users

"An investment in knowledge always pays the best interest." - Benjamin Franklin

hi

Nick Morrott a écrit :
> On 19 August 2010 17:08, Kenni Lund <kenni at kelu.dk> wrote:
>
>>> Inspired by the XMLTV validation tester [1], I've repurposed the code
>>> [2] and put together a tool to monitor the status of all translations
>>> in MythTV trunk, by revision, language and component. The design is
>>> simple and mostly borrowed from the XMLTV tester, but I hope it
>>> conveys the important information clearly:
>>>
>> That's really nice, I was going to setup something like this, but you
>> beat me to it :)
>>
>> Would it be possible to add the latest -fixes branch to the status
>> page? IMHO that would say much more about the status of the language,
>> since it doesn't really make that much sense to update a language in
>> trunk, until the themestrings are updated just prior to release of a
>> new MythTV version.
>>
>
> Certainly possible, and a very sensible idea. I might add the -fixes
> to a separate set of status pages to keep trunk and previous fixes
> branches separate (would make maintenance a lot easier).
>
> Coincidentally, the themestrings have /just/ been updated, and you can
> see the marked drop-off in the overall % numbers on the status page.
>
>
>> Take the Danish translation as an example: According to the trunk
>> status page, only 88% is translated in trunk (giving it an orange
>> color - a bit like a warning). That's really not because we're lacking
>> behind, it's just because we don't send any translations before the
>> themestrings are updated in SVN, which should happen somewhere around
>> the feature freeze. If you make the same statistics on the latest
>> stable version, you should get 100% (or perhaps 99% if a string or two
>> have been changed since the 0.23 release).
>>
>
> I will try and get this done in the next week.
>
>
>> Another thing, do you generate new themestrings every time you
>> generate new statistics for trunk? If not, the current statistics only
>> shows half the truth.
>>
>
> The status updates are currently using an uncompiled source checkout,
> so themestringstool is not run (only lupdate). This can be changed in
> the script.
>
>
>> I would probably generate the new themestrings on each trunk status
>> generation but just leave it out for each -fixes status generation, as
>> it doesn't/shouldn't change any more after release.
>>
>
> Perhaps it might be a good idea to update the status less (~1
> update/month?) during the development cycle (release -> release +5
> months) and then update perhaps once or twice a week once the code is
> frozen and translations start to be submitted and applied? I notice
> from 0.23-fixes that translations are backported after release, so it
> seems sensible to continue to track the -fixes branch up until the
> next version becomes frozen and all efforts go into that.
>
> Many thanks for your (and Nick's) very useful feedback,
> Nick
>
>
Perhaps it possible to have fixed dates (except during the freeze
period) for this update; for exemple january et june are months for
translators.
At the beginning of month you run lupdate and at the end of the same
month, themestringstool run et update the status.
It's more easy to remember
and perhaps january and june for trunk
and march et october for last branch
or in the same time ?

Sorry for my bad english


Gilles (french team translator)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-translators/attachments/20100821/54ad1342/attachment.htm>

2010/8/21 Nick Morrott <knowledgejunkie at gmail.com>:
> Coincidentally, the themestrings have /just/ been updated, and you can
> see the marked drop-off in the overall % numbers on the status page.

Cool, do we know if this is an intermediate update or the final string
freeze (given no errors are found)?


>> I would probably generate the new themestrings on each trunk status
>> generation but just leave it out for each -fixes status generation, as
>> it doesn't/shouldn't change any more after release.
>
> Perhaps it might be a good idea to update the status less (~1
> update/month?) during the development cycle (release -> release +5
> months) and then update perhaps once or twice a week once the code is
> frozen and translations start to be submitted and applied?  I notice
> from 0.23-fixes that translations are backported after release, so it
> seems sensible to continue to track the -fixes branch up until the
> next version becomes frozen and all efforts go into that.

Sounds reasonable. However, I don't know how the backporting of
translations to -fixes will be handled in the future, I think most of
the backported translations to 0.23 was just due to people missing the
deadline before final release. I haven't followed it that closely, but
I think the backporting stopped after a few weeks.

Best Regards
Kenni