On Thursday 30 June 2011, Konrad Rosenbaum wrote: > On Wednesday 29 June 2011, David Faure wrote: > > On Wednesday 29 June 2011, Konstantin Tokarev wrote: > > > 29.06.2011, 03:30, "John Layt" <[email protected]>: > > > > * In Qt5 should remove forced context from Qt to restore > > > > compatability with all other translation systems. > > > > > > Automatic context is a great feature of Qt translation systm, please > > > don't remove it. > > > > What is great about it? IIRC it's typically set to a C++ classname, and > > translators don't typically know these names at all. > > Then maybe we need some way to annotate class names for translators. In my > projects I use contexts extensively, because sometimes translation can > depend on context.
And that's exactly what the "comment" is about, or can be about if used extensively. In KDE we don't have automatic (classname-based) context, instead we use KUIT. http://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics See example below. > Another use case is customized localization. For one of my projects the > customer maintains his own localization file to adapt program output to the > vocabulary that the users are accustomed to and to make it more verbose. So > for example in one dialog it translates "Cancel" to "Abort this > transaction" and in another to "Return to main window". ... Exactly. And a classname isn't enough information to know this, you need a proper "hint for translators". For instance: i18n("@action:button Abort Transaction", "Cancel") vs i18n("@action:button Return to Mainwindow", "Cancel") Qt can already do that, with the "disambiguation" argument to tr(). Let's not mix disambiguation with automatic classname-based contexts. -- David Faure, [email protected], http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
