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

List:       kde-i18n-doc
Subject:    Re: Different formulas for plurals in Qt and KDE
From:       Aurélien Gâteau <agateau () kde ! org>
Date:       2014-04-11 9:22:11
Message-ID: li8c84$7on$1 () ger ! gmane ! org
[Download RAW message or body]

Soenke Dibbern wrote:

> Op Du., den 10. Apr.'14, hett Aurélien Gâteau Klock 17.53 schreven:
> 
>>>> I just did some testing.
>>>>
>>>> 1. I created a nds .po from a .pot with:
>>>>    msginit -l nds -i kbookmarks5.pot -o kbookmarks5.po
>>>>
>>>> 2. Wrote some dummy strings as translations.
>>>>
>>>> 3. Converted the .po into a .ts (Qt translation source format):
>>>>    lconvert -i kbookmarks5.po -o kbookmarks5.ts -target-language nds
>>>>
>>>>    This created a .ts whose root element has an attribute
>>>> 'language="nds"'
>>>>
>>>> 4. Compiled this .ts in a .qm (Qt translation binary format):
>>>>    lrelease kbookmarks5.ts
>>>>
>>>>    This created a kbookmarks5.qm
>>>>
>>>> 5. Installed kbookmarks5.qm in share/locale/nds/LC_MESSAGES
>>>>
>>>> 6. Tried test program kbookmarkdialogtest and... no matter how many
>>>> environment variables I set, I was not able to get it to load my .qm.
>>>> Sad.
>>>>
>>>> If I hardcode the path to the .qm, it gets loaded and translations
>>>> appear,
>>>> though I don't expect proper plural support. After much reading of Qt
>>>> source
>>>> code, I found out locales are defined based on http://cldr.unicode.org/
>>>> so I
>>>> think the best thing to do is to submit the missing languages to cldr
>>>> and
>>>> file a Qt bug to ask for a refresh. As of now, Qt is based on cldr
>>>> v23.1.
>>>> v25 has been released in march but still does not contain nds.
>>>
>>> Moin Aurélien,
>>>
>>> thank you for digging into this. I feared something like this would
>>> happen
>>> when I read 'hardcoded into Qt'. I fear that KDE will lose some
>>> languages
>>> (or at least correctly pluralised tier 1 modules in these languages, if
>>> I
>>> understand matters correctly*) due to this,
>> We could try to bypass QLocale to load the .qm manually by reading
>> environment variables ourselves, but that would still not give you proper
>> plural support.
> 
> Well, if translators are aware of this, they probably could work around
> the missing plural support by using general clauses like "minute(s)" or
> "child(ren)" for the time until the language is available in numerus.cpp.
> Not loading the translations at all would be a major drawback, in my
> opinion. (On a side note, this is even fairly easy if we keep the generic
> messages with "minute(s)" and "hour(s)" in them - which would lead to the
> necessity to translate these messages to proper English, as you pointed
> out in the other thread. But then again - in the last time I have seen
> some messages which could use a looking-at by a native speaker, imho. Such
> messages could then be "translated" to proper English as well, without
> marking the message as fuzzy again in all other languages.)
> 
> Of course, such a mechanism is a workaround in itself and doesn't add to
> cleanness, understandability or maintainability of the code. As a
> translator of one of the hit languages, I naturally would prefer such a
> solution - even with wrong plurals. But I don't have to write or maintain
> the underlying code. So the decision is not mine, I fear (keeping fingers
> crossed).

Just added an item to the frameworks l10n TODO list.
> 
>>
>>> because I don't think that
>>> every small language team will have the resources to push their stuff
>>> into
>>> the CLDR database. Hope I'm proven wrong.
>> I learned about CLDR yesterday, so I have no idea how hard it is to get a
>> new language in it, but seeing as it is used by many companies or
>> organizations it looks to me like the time put into adding your language
>> to
>> it would pay off a lot eventually.
>>
>>> *) Tier 2,3,x stuff could use "normal" KDE i18n infrastructure, is that
>>> right?
>> Indeed. A few tier 2 and 3 frameworks do not use ki18n right now (kauth,
>> kbookmarks, kcompletion, kcrash, kdesignerplugin, kdnssd, kjobwidgets,
>> knotifications). Now that ki18n is tier 1, maybe it is a good idea to
>> bring
>> those frameworks back to ki18n?
> 
>  From a systematic point of view, this would be the logic way to go, but
> maybe are there other reasons for not using ki18n?

Linking to one less library is always desirable for performance reasons, but 
I believe the gain may not be perceptible. That is up to the framework 
maintainers to decide I think.

Aurélien

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