i hate to keep you all from wasting even more time, but ... http://doc.qt.digia.com/qt-5.1/qtcore/qtglobal.html#qtTrId https://qt-project.org/wiki/QtInternationalization#43b304ead4174986c238cb4e0c4d5cb0
and on auto-loading: https://bugreports.qt-project.org/browse/QTBUG-34942 (there was actually a lot of related discussion, but i can't find it, so maybe it was nokia-internal. i'll just refer to KComponentData instead now). On Tue, Sep 02, 2014 at 07:01:30AM +0000, Rutledge Shawn 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.) > > 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. > > - 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). > > - 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. > > - 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, for the same reason > that imperative code should not assume too much about the declarative > structure of the UI. > > _______________________________________________ > Development mailing list > developm...@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
