I have a good experience with .ts and Linguist. So here a summary of this. My application is locallized in 6 languages, there are 8200 items with a total of 76000+ words. So, this can be called a big project.
Being the application programmer, I have done the english text. Being french, I have done the french translations. For the 4 other languages, I gave support to 4 different external translators (incl .Japan). Here's my experience: * Automatic context (which is not bug free) has never been a problem for the 4 translators. GUI class names can often give an hint. When something needs more accuracy, we have the comment option for this. If you want to remove this, hmm... you can imagine the amount ot work to update the sources :-( * the most annoying part in the whole process is the following one: the english text is also reviewed by english writers, ie. not programmers, and mistakes are to be correctd or improvements to be done. This task is long and painful. Ideally, there should be a "Jump" button in Linguist (command line configurable), to open the source file and jump to the line where the string is written. * For productivity, I chose to create a small tool to complement Linguist (to edit .ts files), and add these features: 1) To improve my productivity for french translations: support for Google Translate. I don't know for other languages, but for french, this has cut down my translation time by at least 2 (certainly more, in fact, so less typing). Would be so easy to add to Linguist. 2) improved statistics: to better have an overview of what's done and left to do. Important to evaluate translator's time and also pay them. 3) More checking on the translated items, taking the english as reference. This could be application dependent (eg. I sometimes have predefined $variables$ in ui strings, and the spelling must be fault-less). I am not aware of other translation tools, but if there are good ones (eg. support for spelling, translations...), then the possibility to export/import .ts files would be good/enough. Philippe On Wed, 29 Jun 2011 00:30:43 +0100 John Layt <[email protected]> wrote: > Hi, > > This email is a summary of the session on Translation held at the Qt > Contributors summit. The session was lead by Oswald Buddenhagen (Ossi) from > Qt. Please note I've just retyped my rough notes, my lack of knowledge may > lead to my misreporting important points or things Ossi said, so please check > with him first on anything important. > > * Ossi knows what needs improvement but no time to implement it. He is > flexible on the exact details, if someone implements it he will review it. > > * Qt Linguist is in "maintenace mode", no planned updates, other tools are > better, but does now support gettext file formats. > > * In Qt5 should remove forced context from Qt to restore compatability with > all other translation systems. > > * Qt file conversion tools are now good enough to do 100% reliable > conversions. > > * Might be willing to accept .mo binary format but little real point either > way as all available binary formats 'suck'. Could design a new format but > not > really necessary unless worried about high performance/efficiency, and would > just be another non-standard format. Probably best to stick with current > format and use conversion tools to/from Gettext. > > * Is XLIFF an option? v1 not really suited to software translation, v2 > currently in draft, but financial costs to get involved in standardization > process and unlikely to be ready in time. > > * New QTranslator implementation, new qtr() function in global? > > * Will require old tr() and QTranslator with forced context to still be > supported for source compatability? > > * Instantiate QTranslator in QApplication, protect against mixed translations > in case of failed load. KDE to investigate and implement as part of > KApplication => QApplication effort? > > * New QStringFormatter to solve tr() args problem. Community to code? [I > don't understand the problem or solution here :-)] > > * Semantic markup wanted: copy KUIT from KDE, inline markup do rewrite to > Chusselove's revised design. > > * Not yet willing to consider KDE's Transcript scripting, would prefer other > industry solutions to be investigated first. > > * Ossi to do a high-level write-up of the changes so others know what he > wants. > > * KDE to see if we have people willing to work on this > > I'll be posting a version of this to the KDE lists to see if our translation > guys are willing to pick it up. > > Cheers! > > John. > _______________________________________________ > Qt5-feedback mailing list > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
