[Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation)

[Andre Somers]

On 4-9-2014 18:26, Thiago Macieira wrote:
> On Thursday 04 September 2014 13:03:12 Saether Jan-Arve wrote:
>> Somebody already suggested to embed it as a resource, isn't that good
>> enough?
> As long as we also load it by default. We cannot depend on users loading the
> translation file from the resource system.
Fine. Load it by default.
>
>>> Imagine an application that is only run in English (no L10n) and for
>>> which the source code has proper, English messages. Will it occur to
>>> the developers that they have to provide the en_US translation file
>>> from Qt?
>>>
>>> No, it won't. We need to get rid of that file.
>> If we get rid of it we have to provide an alternative way of providing those
>> plural forms, preferably in some language-agnostic API (since Qt does not
>> constrain you to write your source text in English). Unfortunately there
>> are up to 6 different "plural forms" in some languages, and the rules to
>> know which to pick differs greatly depending on the language.
> I'm saying we need a convenience for us, so we don't have to ship a
> translation file, and we write Qt source in English. This convenience could
> also be used by most software, since they are also written in English.
>
> If you write your language source in another language with different plural
> rules, you'll need to use the existing overload and provide a translation from
> your language back to your language again.
That sounds rather short-sighted to me.
It means that an inconsistency is introduced for no good reason at all. 
If you want to have something that works for English only, it would be 
rather trivial to write a free function like this:

QString singularOrPlural(QString singular, QString plural, int value) {
     if (value == 0 || qAbs(value) > 1) {
         return plural;
     }
     return singular;
}

There you go, there's your special tr version. To me, it sounds rather 
silly to abuse tr() to do something you explicitly say is meant for 
those *not* using i10n or i18n. I really see no need to litter Qt this 
way. Note that if you go ahead using the special tr function, you cannot 
simply translate anyway any more. The string and its arguments may be 
different than what you'd have if you wanted to take translation into 
account from the start. As Qt itself will have to deal with translations 
anyway, I also don't see a gain in Qt itself.


>> ..or alternatively we need to be clarify our documentation to explicitly
>> mention that this plural-form-translation feature requires a translation to
>> be installed, even in English.
> Which is what I don't want. This basically requires everyone to always load
> the Qt translation, even if their apps aren't l10n'ed.
So? If they forget, they'll end up with "1 file(s) found" instead of "1 
file found" or "2 files found". Big deal.

>
>> One only need to provide a translation file for the case you are describing
>> if the application developer uses the plural translation feature. If that
>> feature is not used, the translation file is not needed in your case. I
>> assume if an application developer uses that feature, he should also have
>> read its documentation. And if his plural translations doesn't work I would
>> expect him to read that part again. And if he still doesn't manage to
>> deploy the translation file after that, the user will still see "Found 1
>> item(s)" instead of "Found 1 item", which is not the end of the world,
>> really.
> Agreed.
>
> But I'm assuming from your previous message that we use the feature in Qt's
> own sources. Therefore, every single application uses the feature.
A quick search for %n in the Qt .ts files would reveal that. I don't 
have them here, or I would take a peek.
But even so: Qt could pre-load the Qt .qm file by default from an 
internal resource, and I guess that makes sense. There is no need for a 
special tr() version to do that.

André