String Changes on Branches

[Marc Schumann]

2008/8/19 Max Kanat-Alexander <mkanat at bugzilla.org>:
>        I don't think we've ever said anything about this before, but I
> think, to make life easy for localizers, we should try to avoid making
> string changes on stable branches, as much as possible (that would
> currently include the 3.2 branch). Obviously, if something is very
> important, we should fix it, but any non-critical string changes should
> go on trunk only.

Actually, if it's about localizers, the point would rather be
"template change" instead of "string change". Changing a string isn't
all that much of a problem -- for example, if a typo is being fixed in
an English template, then usually there is no change needed at all in
the translated template, because the translated template didn't adopt
the typo in the first place. Same goes for wording polishes.

I find that the one thing deciding whether a template change falls
into the "easy" or the "tricky" category is how readable the diff is.
The other big thing is the size of the conflicted part of the
translated template after a "cvs up".

Examples:
The big changes to the bug template (de-knobbing and that) was
"tricky" -- I ended up translating the affected templates afresh from
scratch.
Changes to user-error.html.tmpl are usually "easy" -- the conflicted
area is most of the time just about the one error code the change is
in. (Exception: changes in lines' trailing blanks.)
Changes to field-descs.html.tmpl are generally "tricky" -- the
conflicted area is always all of the file, no matter whether a line
was added, removed or changed.
Changes in parts with a lot of code and interspersed language,
potentially in need of translation (e.g. "Reply" in script for comment
reply link), is usually "tricky" -- I need to catch changed language
while ignoring code changes already successfully merged by CVS.
Broad changes in indentation (e.g. because of an additional outer loop
or something) are generally "tricky" -- huge diff; need to find out
whether there's content changes interspersed; huge conflicted area.

To the point: most helpful would be two things -- keeping the diffs
readable, and keeping the conflicts small.

To this end, it would help to have:
1- blank lines between paragraphs; empty lines between entries in
lists like field-descs.html.tmpl -> keeps conflicts to the affected
lines
2- empty lines always without trailing blanks, or at least keep them
as they are now (better even: no trailing blanks anywhere) -> keeps
conflicts small
3- no indentation changes on stable branches -> keeps diffs readable
and conflicts small

With these, I'd feel a significant increase in happiness. I'm
confident that these aren't even too much to ask :)

Bonus points given for
- separation of code and language, separated by empty lines -> keeps
conflicts small; code merges automatically on cvs up
- readable templates: no ties to English grammar (e.g. bug 394248)

>        The ideal would be to keep a single localization pack working
> from rc1 all the way down the branch.

I agree. It'd be nice for admins, too -- no need to delay the security
update because not all localizations are up to speed just yet.
As a localizer, I'd say it's not that critical. Generally, branch
updates turn out to be Mostly Harmless.

   Marc