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 trac-dev+unsubscr...@googlegroups.com. To post to this group, send email to trac-dev@googlegroups.com. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
