On Sep 2, 2014, at 9:01 AM, Rutledge Shawn <shawn.rutle...@digia.com> wrote:
> > On 1 Sep 2014, at 8:32 PM, Thiago Macieira wrote: > >> On Monday 01 September 2014 12:50:23 Graham Labdon wrote: >>> Hi >>> My application is internationalized, however, in some circumstances I need >>> the English version of the string no matter what translator is being used. >>> Anyone have any suggestions on how to achieve this? >> >> You have the English text. The way to get the English text from that is to >> use >> it as-is. >> >> Don't translate, don't transform it in any way. > > Some projects like to use "programmer shorthand" for strings and then leave > the final text up to a different team. Such teams tend to be capricious and > change the English text multiple times (PR and marketing reasons), so it's an > advantage not to treat the English text as the key for looking up the > translation. (And then the shorthand can be written in any language the > programmer likes, too.) If your english translation is done in a separate .qm file (i.e. you do not use the tr-keys for the english text), your application can create a separate QTranslator that you use to load the english translation separately. You just do NOT INSTALL that translator into your app, but instead use that translator directly yourself if you want to access a specific english translation, with englishTranslator.translate(context, text, ......). > I had a previous job like that. They had their own cross-platform > cross-toolkit translation system, so I wasn't allowed to use tr() at all, and > they convinced me that their way was better. They wanted to have all the > strings for all the languages inside the binary. And there was a utility to > generate an enum for the shorthand strings. Imagine opening up Designer and > creating a button, and setting its label to BUTTON_OK. Then you run uic. > Then you post-process the generated header file and make it do something like > tr(BUTTON_OK), which will use the enum to look up the actual string at > runtime, in a fixed-length array in which all strings for a particular > language are stored. > > - Since the header modification is part of the build process, it costs the > developer no time at all if the translation team wants to change the English > text. They do their work independently, and then the application is > re-built. Since the text that is put in tr() is just used as a fallback, there is nothing preventing anyone from providing a separately created english translation (or change individual texts if they are supposed to change). In “your” code that tries to load the correct translation for the current locale, you can fallback to loading this english translation instead of using the tr-key fallback. Of course you might end up with lots of strings in your application that are only used as a key. > - At runtime, this kind of lookup is much more efficient than the usual Gnome > and KDE ways of looking around the filesystem for separate translation files > (but at the cost of bloating the binary somewhat). I would have thought that it is possible to use qrc to add your .qm files to your binary if you really want? Since you define yourself in your app where to look for translations. > - It is clear to everyone when the translation mechanism is not working or > there is an un-translated string: you see the enum shorthand strings instead > of the correct strings - no need to wait for a non-English-speaking tester to > discover it. Linguist keeps track of which strings actually have been translated in some language, so the check “do all strings have translations" is easily automated. I’d expect any translation tool to do that tracking ;). For the check if the translation is actually good/correct you need a native speaker of the corresponding language for testing anyhow in the end. > - There will never be a user who cannot use the app because it wasn't > installed correctly and therefore the translation file was not found: the > strings are guaranteed to be present as long as someone did the translation > work before it shipped. > > The current way of using separate translation files should be kept as a > fallback mechanism though, so that people in countries which were neglected > by the development team can still do their own translations. This is the > good part of the KDE way, that the translation work can be distributed to > lots of people around the world. But it's also possible that they could > contribute their work back to the original git repo, so that some future > build of the application will have those strings built-in. > > I think it's a worthwhile goal that at least commercial Linux binaries ought > to be self-contained and portable, so that there is no installation process > beyond putting the binary in some directory which is in your path. It > wouldn't hurt if the free software community had the goal of zero-install > binaries too. The strings could be packaged as compressed resources, so the > total space consumed is less. And perhaps resources which are not needed for > the current language could even be expunged from memory (at the cost that you > then cannot switch languages dynamically). > > But even if it were not for the enum-lookup implementation that they insisted > on, our assumption that English needs no translation does not fit the > multi-team workflow. There is often an assumption that programmers cannot > design UIs because they are not artistic people or because they don't have > psychology degrees or haven't studied usability enough. This is why we have > separate tools for UI designers to use. It's very similar to the way that > some people assume that programmers cannot write good English either. > Stereotypes in general are wrong, and offensive to people with > multi-disciplinary abilities. Nevertheless we can probably agree that UI > design and the wording of text are often subject to later revision; > so it's useful not to choose a changing string as a lookup key, Actually I’m not so sure about that. If the english (or whatever default language) text changes, that might very well be a hint that all other translations should be adapted too. > for the same reason that imperative code should not assume too much about the > declarative structure of the UI. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
