We plan to write a Trac plugin handling translations. Currently our primary source are Java's resource bundles, but we also plan to support python's PO files. I just created a Trac-Hack [1] for this purpose. As this plugin will be subject of a Bachelor thesis and the Bachelor will start in October the implementation of the plugin has not yet begun. I had just wrote some considerations for this plugin at trac-hacks.
If you have any ideas or suggestions you are welcome to give your 5 cents ;-) [1] http://trac-hacks.org/wiki/TranslationManagerPlugin Best regards, Franz P.S.: I just requested to join the German language translation <https://www.transifex.com/projects/p/trac/language/de/> of the Trac <https://www.transifex.com/projects/p/trac/> project to get to know how Transifex works (and support Trac to be better translated). On Wednesday, July 16, 2014 9:29:43 PM UTC+2, cboos wrote: > > On 2014-07-09 9:54 AM, falkb wrote: > > > > > > Am Sonntag, 15. Dezember 2013 10:30:58 UTC+1 schrieb cboos: > > > > > > As I see it, the main issue here would be the translations. There's > a > > great amount of new or updated translations on Transifex, but they > > haven't been integrated yet. > > > > > > What does "integration" mean here? What is actually to do? I'm actually > > a Qt programmer and there we have just .ts files for each language > > containing the translated texts (edit with Qt Linguist app by the > > translators), they are converted to a binary .qm file, and those .qm > > files are loaded by class QTranslator at runtime. What is the mechanism > > of Trac that got out of control? > > > > What's got out of control is that the current workflow as described in > [1] is way too complicated. I could barely keep up when I was more > involved in Trac, now with some distance I see that it's flawed, we need > to simplify and automate more. The main flaw was that I assumed that > after some time, we'll have an active committer and a team coordinator > for each language (the group 1) and that hasn't happened and won't. > > At this point, I think it's safer to assume that the translators will > prefer to work on Transifex, so that this should become our primary > source. We should have a mostly automated way to download everything > from there (synchronisation point), and commit the result, possibly > after the fixes done after checking the translations for > well-formedness. If such fixes are needed, we should then push them back > to Transifex (possibly overwriting edits done there since the > synchronisation point). > > That's the rough picture. The other idea was to merge all the catalogs > for a language in a single one so that we avoid the problems related to > repeated work and with the merges [2]. > > I'll resume work on that soon, but that shouldn't hold on the imminent > release... > > Speaking about that (0.12.6 / 1.0.2 / 1.1.2), I'm ready to give any > advice or even build the Windows parts, if needed. So Ryan, Jun and > Peter, don't hesitate to ask me if you need anything. > > -- Christian > > [1] - http://trac.edgewall.org/wiki/TracL10N/Transifex > [2] - https://groups.google.com/d/msg/trac-dev/l5YuG7DysOE/cCyyjsiDBE8J > -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
