Hi,
I agree that this is a case-by-case decision, depending on the
application and context. That doesn't contradict making it part of the
translation infrastructure though, does it?
A translator can always make a case-by-case decision depending on the
application and context, and choose which form is appropriate. It's a
bit of extra work for the translator, which is why I would suggest to
make this opt-in somehow.
Since you mentioned CLDR, it acknowledges this in
https://unicode.org/reports/tr35/tr35-numbers.html:
> English does not have a separate plural category for “zero”, because
it does not require a different message for “0”. For example, the same
message can be used below, with just the numeric placeholder changing.
1. You have 3 friends online.
2. You have 0 friends online.
> However, across many languages it is commonly more natural to express
"0" messages with a negative (“None of your friends are online.”) and
"1" messages also with an alternate form “You have a friend online.”.
Thus pluralized message APIs should also offer the ability to specify at
least the 0 and 1 cases explicitly; developers can use that ability
whenever these values might occur in a placeholder.
I guess it depends on how one interprets the last sentence whether it
makes sense to have this as part of the translation infrastructure.
Cheers
Nico
On 5/4/26 10:32 AM, Kai Köhne wrote:
Hi Nicolas,
Interesting! I see that, in a lot of UI texts, 0 is indeed a special
case. It indeeds feels more natural to say “No files copied” than “0
files copied”.
This is not always the case though. “Distance to target: 0 kilometers”
is arguably better than “Distance to target: No kilometers”.
Then there is cases where you might still go for numbers, for instance
if it helps keeping things consistent: It’s at least not clear cut
that “3 errors, no warnings” is preferred over “3 errors, 0 warnings”.
All in all, I therefore think that the special handling of 0 is a
choice that depends on style and context, and not a hard rule defined
in the language. As such, I don’t think it would be a good fit for the
plural infrastructure we currently have in QTranslator, which is
based on objective properties of the languages, as defined e.g. in the
CDLR.
Having said that: Do you have ideas how to better support this use
case without just changing the plural rules? How would you approach it
, keeping in mind that we have to keep backwards compatibility?
Kai
*
Confidential
From: *Development <[email protected]> on behalf of
Nicolas Fella via Development <[email protected]>
*Date: *Thursday, 30. April 2026 at 20:36
*To: *[email protected] <[email protected]>
*Subject: *[Development] Alternative plural forms for English (and
similar)
Hi,
it should be pretty well-known that plurals are a complex topic when it
comes to translating. While languages like English and German generally
only distinguish between Singular and Plural, other languages can have
more complex rules. Qt supports all of that, so far so good.
However, even with English or German there are more subtleties involved.
When having zero items of something the plural form is used: "0 unread
messages" is a perfectly grammatical sentence. It often reads nicer to
instead have "No unread messages" instead though. It's possible to
achieve that with Qt by an additional if check and using a different
string, but this doesn't scale with the number of strings to be
translated and might clash with languages with more complex rules.
Instead it would be nice if Qt's translation system supported this
natively. From the translator's point of view this effectively becomes
an additional plural form (n==0). I've had a look at how hard it would
be to extend Qt to support that. It appears that the QtCore side is
flexible enough to handle this and reads the rules from the qm file, so
it's "just" a matter of teaching lupdate/lrelease about the alternative
plural rules. I've successfully hacked those to change the rules for
English-ish languages to achieve this, but it would probably need to be
opt-in in order to not break existing users that don't want this.
Before I spend more time on this, is this something that Qt would be
willing to support/accept? Are there any other considerations that I
should be aware of?
Cheers
Nico
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
