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
Re: [libreoffice-projects] Re: Workflow between dev, UX and l10n teams
On Fri, Jan 30, 2015 at 09:53:42AM +0100, Lionel Elie Mamane wrote: Is there a possibility that git and pootle are more-or-less constantly kept in sync? Interestingly, doing a web search for pootle git synchronisation leads me to http://weblate.org/en/features/ :-) -- Lionel -- 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: Workflow between dev, UX and l10n teams
Hi, Le 30 janv. 2015 12:25, Lionel Elie Mamane lio...@mamane.lu a écrit : On Fri, Jan 30, 2015 at 12:14:04PM +0100, Bjoern Michaelsen wrote: On Fri, Jan 30, 2015 at 10:06:36AM +0100, Lionel Elie Mamane wrote: Interestingly, doing a web search for pootle git synchronisation leads me to http://weblate.org/en/features/ :-) Well, once we dont require to be self-hosted anymore, https://translations.launchpad.net/ certainly would be an option too. However, IMHO there are very good reasons to be self-hosted with translations. From glancing at the webpage, Weblate is a software that we can host ourselves. This is something the l10n team has already in his radar. But please, before changing our tool and our workflow, let's discuss at Fosdem with Dwayne from the Pootle team what we can achieve. Cheers Sophie -- 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: Workflow between dev, UX and l10n teams
On Fri, Jan 30, 2015 at 12:14:04PM +0100, Bjoern Michaelsen wrote: On Fri, Jan 30, 2015 at 10:06:36AM +0100, Lionel Elie Mamane wrote: Interestingly, doing a web search for pootle git synchronisation leads me to http://weblate.org/en/features/ :-) Well, once we dont require to be self-hosted anymore, https://translations.launchpad.net/ certainly would be an option too. However, IMHO there are very good reasons to be self-hosted with translations. From glancing at the webpage, Weblate is a software that we can host ourselves. -- Lionel -- 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: Workflow between dev, UX and l10n teams
On 01/19/2015 11:03 AM, Sophie wrote: - if there is a way to script changes, script them otherwise wait until there is a script available to commit them I am not sure I understand you here (to me, the otherwise part reads: if there is no way to script changes, wait until there is a script available, which would not make sense). 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). -- 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
[libreoffice-projects] Re: Workflow between dev, UX and l10n teams
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?] 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? Also - should we have a 'Localization' recurring topic in the ESC? Who would be the right representative there, please? All the best, Kendy -- 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: Workflow between dev, UX and l10n teams
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 -- 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: Workflow between dev, UX and l10n teams
Hi Kendy, Le 26/01/2015 16:40, Jan Holesovsky a écrit : Hi Sophie, Sophie píše v Po 26. 01. 2015 v 16:19 +0100: 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. But the offline files are taken from Pootle too - right? So if fixes are done at the time of uploading to Pootle, everybody gets them - correct? yes, I'll have a meeting with Dwayne (Pootle developer) during Fosdem and will discuss with him about that. 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. Yes, I'm not sure either 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... It was brought on the dev list, but when the l10n team discovered it, it was too late. Cloph has already scripted several changes, but he can't do it all. Translators are for most of them non technical people and will not see a commit, but only the result on Pootle, sometimes months later. The months later is the problem, not the non-technicality :-) It is enough to send something happened yesterday - please check what's up; similarly to how people are checking the daily builds. that will be possible now that some of us are translating on master 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. Well - if it's not recurring, it's easy to forget ;-) Also I think it will be more effective to discuss this there - are you able to join this Thursday? Thanks for the invitation and yes, let me know the time and I'll join. Cheers Sophie -- Sophie Gautier sophie.gaut...@documentfoundation.org Tel:+33683901545 Co-founder - Release coordinator The Document Foundation -- 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: Workflow between dev, UX and l10n teams
Hi Sophie, Sophie píše v Po 26. 01. 2015 v 16:19 +0100: 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. But the offline files are taken from Pootle too - right? So if fixes are done at the time of uploading to Pootle, everybody gets them - correct? 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... Translators are for most of them non technical people and will not see a commit, but only the result on Pootle, sometimes months later. The months later is the problem, not the non-technicality :-) It is enough to send something happened yesterday - please check what's up; similarly to how people are checking the daily builds. 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. Well - if it's not recurring, it's easy to forget ;-) Also I think it will be more effective to discuss this there - are you able to join this Thursday? All the best, Kendy -- 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
