RFC: i18n: strict translation call-to-catalog mapping

2012-04-03 Thread Chusslove Illich
(This is the second and the last thing I want to change in i18n for KF5, honestly.) At present (and since forever) it is practically indetermined from which catalog exactly an i18n() call will fetch the translation. All loaded catalogs in the process are tried in mostly arbitrary order, depending

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-03 Thread Albert Astals Cid
El Dimarts, 3 d'abril de 2012, a les 20:05:14, Chusslove Illich va escriure: > (This is the second and the last thing I want to change in i18n for KF5, > honestly.) > > At present (and since forever) it is practically indetermined from which > catalog exactly an i18n() call will fetch the translat

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-04 Thread Thomas Zander
On Tuesday 03 April 2012 20.05.14 Chusslove Illich wrote: > At present (and since forever) it is practically indetermined from which > catalog exactly an i18n() call will fetch the translation. All loaded > catalogs in the process are tried in mostly arbitrary order, depending when > and which libr

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-04 Thread Chusslove Illich
>> [: Chusslove Illich :] >> For C++ code, I couldn't think of a better solution than that advised for >> plain Gettext, and e.g. as formalized in Glib. It would amount to having: >> >> #define TRANSLATION_CATALOG "foolib" >> #include "KLocalizedString" > > [: Albert Astals Cid :] > This means

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-04 Thread Chusslove Illich
> [: Thomas Zander :] > First, any Qt tr call has a context (typically the class name), am I > correct that i18n() still does the same thing? It doesn't: context is added manually, when judged or reported to be needed. (And this is how it always was.) > Can you explain a bit more how things are u

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-04 Thread Thomas Zander
On Wednesday 04 April 2012 21.11.22 Chusslove Illich wrote: > > First, any Qt tr call has a context (typically the class name), am I > > correct that i18n() still does the same thing? > > It doesn't: context is added manually, when judged or reported to be > needed. (And this is how it always was.

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-04 Thread Oswald Buddenhagen
On Wed, Apr 04, 2012 at 09:25:10PM +0200, Thomas Zander wrote: > On Wednesday 04 April 2012 21.11.22 Chusslove Illich wrote: > > > First, any Qt tr call has a context (typically the class name), am I > > > correct that i18n() still does the same thing? > > > > It doesn't: context is added manually

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-05 Thread Chusslove Illich
> [: Oswald Buddenhagen :] > fwiw, irrespective of the missing hierarchy, the real problem is of course > that all these short strings are not properly annotated. In practice, this would be sufficient if people were very careful (see next point). But, there is the more basic issue of one piece of

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-05 Thread Oswald Buddenhagen
On Thu, Apr 05, 2012 at 12:14:35PM +0200, Chusslove Illich wrote: > > scripty should make reports and bug the respective maintainers when > > strings do not comply with some minimum disambiguation criteria (these > > could be statistically determined). > > Krazy has been doing this for several yea

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-06 Thread Thomas Zander
On Wednesday 04 April 2012 22.40.22 Oswald Buddenhagen wrote: > chusslove understood you perfectly well. ;) Good. > gettext never did that. > and in qt these auto-contexts are a pita, as they lead to a lot of > duplication within a single catalog. it's really not the right solution. > so chusslov

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-06 Thread Chusslove Illich
> [: Oswald Buddenhagen :] > the "inlined" should be hint enough that i'm talking about code size. even > small inefficiencies add up, so a functionally equivalent but more > efficient solution is generally preferable. You have got to be kidding me. Gettext designers apparently haven't thought abo

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-06 Thread Chusslove Illich
> [: Thomas Zander :] > I like that idea in general, not sure how to implement it properly, > though. Simplest idea is to make cmake generate a "klocale-{module}.h" > file and make everyone include that. But that sounds like a lot of work. Actually I have nothing against providing any kind of spec

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-06 Thread Oswald Buddenhagen
On Fri, Apr 06, 2012 at 10:45:30AM +0200, Chusslove Illich wrote: > > [: Oswald Buddenhagen :] > > even small inefficiencies add up, so a functionally equivalent but > > more efficient solution is generally preferable. > > You have got to be kidding me. [...] > if you consistently apply this atti

Re: RFC: i18n: strict translation call-to-catalog mapping

2012-04-06 Thread Thomas Zander
Quoting Chusslove Illich : [: Thomas Zander :] I like that idea in general, not sure how to implement it properly, though. Simplest idea is to make cmake generate a "klocale-{module}.h" file and make everyone include that. But that sounds like a lot of work. Actually I have nothing against prov