[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Best practices with Qt translation contexts?
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2015-07-16 20:16:46
Message-ID: 5212428.QvTSVAOQZl () xps
[Download RAW message or body]

El Dimecres, 15 de juliol de 2015, a les 13:48:59, Friedrich W. H. Kossebau va 
escriure:
> Am Donnerstag, 9. Juli 2015, 22:00:44 schrieb Albert Astals Cid:
> > El Diumenge, 5 de juliol de 2015, a les 16:51:34, Friedrich W. H. Kossebau
> > va
> > 
> > escriure:
> > > Hi translators (and developers here),
> > > 
> > > for KDE projects that would like to avoid the dep to the KI18n framework
> > > module (for whatever reasons), is there some (KDE-specific) guide how to
> > > best use that concept of "class" contexts?
> > > 
> > > From what I understand, the "class" context in Qt translation system is
> > > similar to the "domain" in the KI18n system, just that the name of the
> > > domain is also used as id for the catalog with the translations, while
> > > the
> > > "class" context does not have a relation to the catalog name, but serves
> > > as
> > > a 1st level lookup table, with the disambiguation as optional 2nd level
> > > lookup table.
> > > 
> > > I have seen some code which simply does QObject::tr() in all code that
> > > is
> > > not in methods of QObject subclasses. Which seemed not perfect to me,
> > > because a) this might rather result in conflicts with translations from
> > > other libs if they use the same approach?
> > 
> > Yep
> > 
> > > b) translators actually like the context given by the "class"?
> > 
> > I'd say it's somewhat useful, but not that much.
> > 
> > > I played around with QCoreApplication::translate("ClassContext", ...)
> > > and
> > > Q_DECLARE_TR_FUNCTIONS to avoid the longer first variant, and also by
> > > using
> > > the tr() method of classes that already got it defined.
> > 
> > Have you checked what other frameworks do?
> 
> Yes (that's e.g. where I also saw QObject::tr() used here and there), but I
> could not make that much sense of it :) I.e., derive some best practices out
> of it. So I decided it's better to ask the humans behind why they do what
> they did, given I can reach them, instead of making uneducated guesses :)

You probably want to ask the humans from kde-frameworks-devel then, i think i 
remember that at some point they were using ::translate() and then moved to 
tr() or viceversa.

> 
> So by current reply here it seems not that much positive or negative
> experience has been made that there are guidelines to "please stick to", at
> least when it comes to that "class" context?
> Besides
> * Avoid QObject::tr() to prevent conflicts when looking up the string
> (I assume usual recommendations for disambiguation context stays the same as
> with the ki18n system)
> 
> Okay. Then thanks for that for now :) Will now also poke in the core-devel
> mailinglist directly to see what they could add to this. Then would return
> here to see where we should put that little bit of guidelines and how, to
> e.g. https://techbase.kde.org/Development/Tutorials/Localization/i18n
> and
> https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Syste
> ms

Cool, thanks for the effort!

Salut,
  Albert

> 
> Cheers
> Friedrich

[prev in list] [next in list] [prev in thread] [next in thread]