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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
