On 19 March 2015 at 18:44, Andrej N. Gritsenko <and...@rep.kiev.ua> wrote: > Hello! > > Jerome Leclanche has written on Thursday, 19 March, at 17:26: >>On 19 March 2015 at 12:11, Andrej N. Gritsenko <and...@rep.kiev.ua> wrote: > >>> >From developer point of view I would need to be able to do sync from GIT >>> to Pootle and do sync from Pootle to GIT at some point (on templates >>> update or before software release respectively) so developer should have >>> access to do it at will. As for daily sync without any intervention from >>> translators, that should be very good for them: from translator point of >>> view those additional clicks are confusing for newbies but if translator >>> forgets to do it, that brings problems later. > >>What we do for most of our instances is we have a continuous cycle >>that is so fast that people never need to worry about manually >>triggering it (Mozilla pulls in every hour, Evernote every 15 >>minutes). > >>Regarding syncing from git to Pootle, that is something we are keen on >>no longer supporting. It creates several inconsistency issues, some of >>which we are currently hitting in 2.6. We have spent a lot of time >>thinking about and drafting a solid "translation in code" model. 2.7 >>is a step in the right direction, but this is an ongoing usability >>experiment as well. > > Well, your changelog says: > > Update against templates - do template updates outside of Pootle and use > :command:`update_stores` to load the changed files. > > What I meant is exactly this - developer updates template outside of > Pootle and then wants Pootle to integrate updates to be used by all the > translators, so how it would be performed now? By asking an administrator > to issue that command or it is still available in web interface?
It's part of the script that will be periodically run, so once the template is committed, the developer doesn't have to think about it any further, Pootle will seamlessly pick it up. > >>To be honest, translations should not even be version controlled >>alongside the code but in their own VCS (in this case, Pootle would be >>the VCS, but it could also be a separate git repository). We are >>actively discussing these issues with the translation community and >>all of this is still up for debate. > > This is very much inconvenient due to a lot of extra work for any > developer to merge two different VCS (especially if they are different > kinds) and keep them in sync, it may even require some extra means to > resolve unsync conflicts, which will be a burden for developers, so I'm > afraid many developers will give up that and never be bothered with > translations but let third-party enthusiasts to bother with it instead. > That is not good for any project, it's why only very massive projects can > afford that model with isolated translations, not small or medium sized > projects. Right - I went on a bit of a theoretical tangent. Practically, the translations will still be in git, but that makes the git log fairly noisy. The advantage of not having translations in git is that it doesn't pollute the log and credit can be a lot more accurately assigned (in fact, we have a scoring system in 2.7 which "rewards" more active translators). So when you build your program, you can build it untranslated, or pull in the latest translations (`make` could run something like "wget http://pootle.lxde.org/export/?project=pcmanfm"; and unzip it to the appropriate location. You'd do the same thing when you do a release). There's no merging of any kind to be done. The other way around though (commit translation changes directly to git and expect pootle to pick them up) is what's no longer supported. It's something we currently do in LXQt, but AFAIK LXDE does not do it - am I wrong? > > With best regards, > Andriy. > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Lxde-list mailing list > Lxde-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxde-list ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Lxde-list mailing list Lxde-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list
