Re: [libreoffice-projects] Re: Workflow between dev, UX and l10n teams
Hi Lionel, 2015.01.30 10:53, Lionel Elie Mamane wrote: On Wed, Jan 28, 2015 at 09:02:52PM +0200, Rimas Kudelis wrote: 2015.01.28 11:20, Stephan Bergmann wrote: When talking about (developer-side) scripting, is it actually OK to commit modifications to the translations in the translations git sub-repo? My understanding was that such modifications would be overwritten by the next import commit (as typically done by Andras, AFAIU from some Pootle database). The process as I see it would be somewhat like the following: when we have a big enough string change, which can be scripted coming up, it should be announced at least a few days in advance, that on day X time Y, this change will land. (...) On day X time Y, we close down the affected Pootle project, push its localizations into git, then somebody who's in charge checks them out of git and runs the script. When the script finishes its work, the resulting files are committed back to git, imported back to Pootle and the project is re-opened for translation. Once that is done, an announcement should be sent to the L10n list with huge thanks for everyone's patience and kudos to everybody involved in the process. And we all live happily ever after. :) While I understand the concerns that underlie your idea, that process is so heavy that we are just going to lose drive-by contributions like e.g. the commits I did in August 2014 (which possibly no one noticed and somebody else redid most of the work again independently...). http://cgit.freedesktop.org/libreoffice/translations/commit/?id=d9ae641365f094cc1898d7f614dc8a72a1c6b914 http://cgit.freedesktop.org/libreoffice/translations/commit/?id=34a7cd1e0959023b5fb0fa0e5873bcc67ae026e4 http://cgit.freedesktop.org/libreoffice/translations/commit/?id=1a15415c3fe875ee4193fbdbcbd0ebde3b13b48 I'm not sure exactly how such drive-by commits are relevant to this case. I don't think anyone is taking care to watch for such commits at the moment and import them into Pootle. I imagine that right now, only locale that gets imported into Pootle periodically is the source locale (en-US). Any changes to other locales, like this change of yours, are doomed to be overwritten on next export from Pootle, unless you do them in Pootle itself instead. Is there a possibility that git and pootle are more-or-less constantly kept in sync? For example: 1) a git hook (script run automatically each time a push is done) that pushes the changes to pootle as soon as they are pushed to git (just like we mirror our git repo(s) to freedesktop). 2) the same from the pootle side, as soon as a translator makes a change, it is exported to git. 3) There is a theoretical race condition for conflicts (although the window could be kept to a few seconds...). In case of merge conflict, error out and mail a human for manual merge? Considering the size of our project and the amount of files, I'm afraid that both these things would be impractical at the moment, here's why: 1) Exporting files from Pootle takes a lot of time currently. Exporting only the relevant file on string submit would likely be faster, but still not fast enough, I'm afraid. 2) Furthermore, even assuming that speed would be acceptable, making a separate git commit for each string change would blow the size of repository considerably and litter the commit log with thousands of commit messages. Also, I suspect tree deviations might be unavoidable, and merges might be required. 3) Regarding importing changes from git into Pootle – it's also slow, it would likely be faster if import would be done for just the affected files. Then again – how often do such drive-by commits happen? My guess is not very often. So I don't think that is the scenario we should tailor for. I can't open the git commit log page at the moment (perhaps the repository is already too huge for cgit?), but if among the developers there are only a handful exceptions like you, who want to also contribute to their locale, perhaps the best option for them currently is to do it using Pootle itself, or by contacting the localizer in charge? I know that it seems much easier to just fix the problem, but as you saw yourself, that doesn't quite work in our case. On the other hand, the massive changes that we are discussing here are a whole different beast: they are massive and they affect all locales, because they change many strings in the source locale. And they are often scriptable. And they drive localizers nuts, if not done properly. :) By the way, I just glanced over your commits, and it seems you mostly removed spaces in some help SGML tags. Were these spaces breaking anything? Also, the last commit you linked to mentions BugZilla. I feel obligated to say that Bugzilla is called Bugzilla and not BugZilla (just like Firefox is not called FireFox, and Microsoft is not called MicroSoft, and we are not called Libre Office with a white-space in the middle). That misnaming
[libreoffice-projects] Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
Hi Jan, 2015.01.26 16:43, Jan Holesovsky rašė: 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. 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 does offer the original translation, but the localizer still has to approve it. Furthermore, Pootle does not apply any automatic changes. If you had e.g. Some ~string, and you change it to Some _string, Pootle will show the original translation as a hint, but the user will still have to port this trivial change to the translation manually. Needless to say, sometimes these minor differences avoid being noticed by the localizers, which results in errors in the locale (I've seen incorrect access key identifiers in the menus at least once). However, while you are correct that there is no tool to detect these changes, I don't think there has to be. The person who implements the change knows better than anyone whether or not it can be automated, perhaps they even automated it themselves. For example, I seriously doubt that somebody went over all L10n files and changed triple dots to ellipses manually, this was most likely a scripted change. Same, or very similar, script would have probably worked with all other locales, but I guess that person simply didn't think about it. Similarly, changes in used quote characters most likely could have been isolated and transplanted to locales. Adding colons to certain strings only would probably have been slightly more difficult, but still scriptable. And none of that requires any tool to detect trivial changes... ;) 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 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. 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. 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? I fully agree with you here, and yes, so far communicating these issues was really difficult because these massive changes appeared in front of the localizers' eyes way too late in the process. Regards, Rimas -- To unsubscribe e-mail to: projects+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/projects/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-projects] Re: Workflow between dev, UX and l10n teams
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 -- To unsubscribe e-mail to: projects+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/projects/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-projects] Workflow between dev, UX and l10n teams
Hi again, On 2015 m. sausio 28 d. 09:09:27 EET, Rimas Kudelis r...@akl.lt wrote: On 2015 m. sausio 28 d. 08:10:38 EET, jonathon toki.kant...@gmail.com wrote: BTW, when you say style guide, which specific one do you mean? The one you're looking for, assuming it exists. If not, or could be a combination of Gnome HIG and any American English style guide we (the LibO community) would deem acceptable and meeting our needs (e.g. The Chicago Manual of Style). In fact, I just thought that it doesn't even have to be a formal manual: if somebody would be willing to oversee style consistency in our strings, and that style would look acceptable by our en-US users, then why not? Especially if that person would be willing to formalize these rules into a written style manual along the way. -- Rimas -- To unsubscribe e-mail to: projects+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/projects/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-projects] Workflow between dev, UX and l10n teams
Hi Jonathon, 2015.01.27 23:15, jonathon wrote: On 27/01/15 18:36, Rimas Kudelis wrote: If you need to review *all* help UI, I think it maps to an equivalent of a 500 or more page handbook. But you don't. L10n only are only asking for review of strings when they are being changed. Review strings in context. Whoever volunteers for this task will need to go through _all_ of the existing help, UI, and other things, before reviewing strings when they are changed. The task requires: * Copy editing; * Line editing; * Proof reading; amongst other editing tasks. FWIW, this also means that the l10n, a11y, and i18n teams will be dumped with a slew of changes that might, but probably won't affect their existing translation, but will still need to be verified to ensure that their translations, etc. are not broken. I really don't see a revision of all existing strings as a requirement to start reviewing newly added ones. Of course, it would be beneficial, but not at all a requirement. You don't need to read a 500-pages worth of text to tell whether or not a certain string is clear, concise and grammatically, syntactically and typographically correct. Especially if you are a native English speaker and have a style guide at hand. Rimas -- To unsubscribe e-mail to: projects+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/projects/ All messages sent to this list will be publicly archived and cannot be deleted
[libreoffice-projects] Re: New DL-Page - request for updated Translations
Hi all, I just made a pull request: https://github.com/tdf/cms-code/pull/10. This updates the existing translations and adds some new ones. Rimas 2013.07.17 13:00, Christian Lohmaier rašė: Hi *, as discussed previously on the website mailing list, the Button-Download page will get a functionality facelift, and will be integrated better with the donate page. See http://www.mail-archive.com/website@global.libreoffice.org/msg11340.html and follow-ups for a description of the changes. Some strings were changed/added, so if you could please provide updated translations.. I received a couple via mail already. But far from the complete list :-) See https://github.com/tdf/cms-code/commit/6efa4d4492a5faf5fe53e1500f6900777c616aeb#diff-3 for the changed/added strings. and http://staging.libreoffice.org/download/ for context of the strings. ciao Christian -- To unsubscribe e-mail to: projects+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/projects/ All messages sent to this list will be publicly archived and cannot be deleted
[libreoffice-projects] New DL-Page - request for updated Translations
Hello, L10n, to satisfy the request quoted below, I've just updated the website project on Pootle to contain new strings. The update brings 71 new words. Please update your translations by the end of this week, so that I can make a pull request early next week. Regards! Rimas 2013.07.17 13:00, Christian Lohmaier wrote: Hi *, as discussed previously on the website mailing list, the Button-Download page will get a functionality facelift, and will be integrated better with the donate page. See http://www.mail-archive.com/website@global.libreoffice.org/msg11340.html and follow-ups for a description of the changes. Some strings were changed/added, so if you could please provide updated translations.. I received a couple via mail already. But far from the complete list :-) See https://github.com/tdf/cms-code/commit/6efa4d4492a5faf5fe53e1500f6900777c616aeb#diff-3 for the changed/added strings. and http://staging.libreoffice.org/download/ for context of the strings. ciao Christian -- To unsubscribe e-mail to: projects+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/projects/ All messages sent to this list will be publicly archived and cannot be deleted
