Reminder: default branch is closed

[Martin Geisler]

Wagner Bruna <wagner.bruna+mercurial at gmail.com> writes:

> On 01/26/2012 06:14 AM, Martin Geisler wrote:
>> Matt Mackall <mpm at selenic.com> writes:
>>> On Wed, 2012-01-25 at 14:19 +0100, Martin Geisler wrote:
>>>>
>>>> (...)
>>>>
>>>> I've considered to ask the translators to only use the default
>>>> branch. This gives them a steady flow of changes and no disruptions
>>>> when default is merged into stable.
>>>
>>> That will result in no i18n changes getting added during freezes. If
>>> anything, translators should work on the stable branch, where there
>>> is less message churn?
>> 
>> I was thinking that it would be nicer to have a steady stream of
>> changes instead of a big change every three months when default it
>> merged into stable. In that way, it feels like default sees less
>> churn than stable where you suddenly get lots of new strings 14 days
>> before the release.
>
> In my experience, it makes more sense to always work on the stable
> branch, because:
>
> - most users run either tagged releases or stable tip, so translation
> updates (and user feedback!) become available sooner;

That's true, but do you really get a lot of feedback? I haven't got any
serious feedback on the Danish translations, except from some fun
remarks from Sune and Henrik :) With the new 3 month release cycle I
think it doesn't matter much where the translation is updated, it will
get into the hands of users soon enough.

Should we consider doing the opposite of my first idea: recommend to
translators that they only work on the stable branch?

In any case: I'm glad the current system is working for you! Maybe it
doesn't need any simplification :)

> - all new messages get reviewed before a major release, since during
> the freeze I need to take a look at them anyway;

I was imagining that it would be just as easy to look at the new strings
throughout the 3 month period leading up to the release.

> - on default, the .po lines tend to jump around a lot due to code
> changes, polluting diff output

I've also noticed that big chunks of the .po file can move around for no
apparent reason... maybe we could sort the strings better?

We strip out the line numbers in the repository today (and also in the
working copy) and I find that annoying from time to time. Without line
numbers, I have to find the right entry in the hg.pot file (where there
is line numbers) and then use that to jump to the definition.

Storing the line numbers in the repository is not nice since it would
generate even bigger and more confusing diffs when the code changes. But
perhaps we could store the file names and strip out the line numbers?

My hope is that msgmerge will stop moving code around if it has full
file names and line numbers for all entries -- we can ask it to sort by
file location.

An encode filter should be perfect for this: it would remove line
numbers when the file is "encoded" before commit. In a new checkout, a
'make xx.po' would add the line numbers again.

> (diff is very useful to spot small changes during translation
> updates). And if the stable and default .po files diverge, any change
> to a .po file on stable may trigger a merge conflict (a smarter merge
> tool for .po files could help here).
>
> FWIW, the last freeze changeset added/changed only ~100 messages on
> stable, from a total of ~3900.

Okay, I'm glad it wasn't worse than that.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/customer-projects/