[libreoffice-projects] Re: Workflow between dev, UX and l10n teams

[Rimas Kudelis]

Hi,

2015.01.26 17:40, Jan Holesovsky rašė:
> Sophie píše v Po 26. 01. 2015 v 16:19 +0100:
>
>> That's why we were thinking of a en_US version as a real language and
>> different from the sources and
> But at some stage this will have to apply to the sources - and at that
> time, it will be even worse than now :-(  I'm afraid having en_US as a
> separate language will make the situation worse, not better.
>
>>  also about scripting changes when
>> possible (like the substitution of ~ by _)
> Sure - so I think this was something that could have been automatized
> with a trivial script; when this was noticed for the first time, please?
> Pity that it was not brought to the ESC as a problem...

I just wanted to say that I'm fully with Jan on these two statements: I
believe that the right thing to do is automation of massive trivial
changes, not a separate pseudo-locale where strings with developer
mistakes and/or without enough clarity would be carved in stone. Having
that pseudo-locale would not help us solve half of cosmetic issues, such
as added colons or changed access keys, these would require scripting
anyway. The issues it would solve are either also scriptable
(typographical or letter case changes) or should be rare by their nature
(typo fixes or sentence improvements; now that some teams work on
master, these should occur in branches even less frequently). On the
other hand, having that source locale would introduce a yet another
level of complexity by forcing each developer to decide where each
string change should go, and if you are thinking about making a single
person or two accountable for these decisions, then why not ask them to
instead review strings that are about to be landed into en-US?

In general, I think it's kind of sloppy (sorry, can't think of a right
word right now) to leave miss-worded strings in the source as they are,
and fix them in a separate locale instead. I don't know how many fixes
like that (specifically excluding typography, colons and similar massive
replacements) end up in each release, but assuming there aren't many
(e.g. a dozen or two), I really don't think they deserve all this fuss.

Regards,
Rimas