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
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 should probably be fixed in the source.
To unsubscribe e-mail to: firstname.lastname@example.org
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 (continued)
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy