Hi Kendy, Le 26/01/2015 15:43, Jan Holesovsky a écrit : > Hi Sophie, Mihovil, > > Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100: > >> Cosmetic changes (~ to _ or "Status" to "Status:" or ... to … or those >> different quote styles I don't even have on my keyboard) and anything >> similliar - NOT OK if you don't script it for all languages >> Cosmetic changes ("Big brown fox" -> "Big Brown Fox") - NOT OK at all, >> change just for en_us, don't change my strings and don't even notify me >> you did it in en_us > > I see 2 problems here: > > 1) There is no tool that would detect these trivial changes, and would > act accordingly. > > 2) The texts for translations are updated in big 'code' drops, without > possibility for translators to affect the process in any way - for > them it is too late. > > Regarding 1) - I thought that Pootle is detecting the trivial changes > some way, and offering the original translation. Is it not? What can > be done to improve that, so that for translators it is just a matter of > checking; not a matter of translating? [Or even what you suggest - that > it would just update the source strings without touching the > translations?]
Pootle will show you a modified string, even if it doesn't affect your translation you will have to validate the string again to have it on a translated state. Also we don't all work on Pootle, several of us are working off line and Pootle is only a repository for our files. That's why we were thinking of a en_US version as a real language and different from the sources and also about scripting changes when possible (like the substitution of ~ by _) > > Regarding 2) - I'm glad that you say that the strings will be now > getting to Pootle immediately after the code / string changes in master. > I think it is important that the translators will be able to deal with > the changes immediately, not several months later, so that they can > cooperate, and not only react. yes, that's much better, even if we have to be cautious about the workflow. > > In general, I don't think that setting extremely strict rules works, > unless you have means how to enforce them - like via a commit hook or so > (and it is extremely unpopular way to do things). > > It is always much better to communicate - if you see a developer who > commits a change that causes you grief, please _do_ tell _him/her_ > immediately, and - if possible - in a friendly way. I'm sure he/she > will do much better the next time. Translators are for most of them non technical people and will not see a commit, but only the result on Pootle, sometimes months later. In the same way the developer who is doing tons of changes for en_US is invited to discuss them with the l10n team :) > > Unfortunately I did not see any signs of notice that this or that change > was problematic for localization on the development mailing list - were > there such warnings there? Like "commit XY caused AB - please don't do > such things, unless we agree how to do that effectively / without pain"? > Or was it impossible so far because the strings in Pootle were not > synced with master? Yes, I think it was too late and when the l10n team is at work, it's the rush i.e RC time for developers, so not the best period to discuss hot topics ;) That's why I've waited to open this discussion. Also, even if I've discussed as much as possible about l10n on issues concerning UI changes, it's a lot of work to follow each commit that could have an effect. Sharing the effort between developers/UX/l10n teams should be possible. As we follow Gnome HIG, adding it as pre-requisite for UI changes/adds may prevent to have to rewrite dialogs for example. > > Also - should we have a 'Localization' recurring topic in the ESC? Who > would be the right representative there, please? Maybe not as a recurring topic, but something that should be in mind of UX team and developers when they commit or check for commits that have a huge impact on l10n. Cheers Sophie -- Sophie Gautier sophie.gaut...@documentfoundation.org Tel:+33683901545 Co-founder - Release coordinator The Document Foundation _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice