Il 24/10/24 18:23, Thiago Macieira ha scritto:
On Thursday 24 October 2024 05:19:45 Pacific Daylight Time Giuseppe D'Angelo
via Development wrote:
Btw, where does the “tr” go? Is it going to be tr(std::format(…)) or
std::vformat(tr(…))?

In the former, we’d have to pass the value twice (once for std::format
to substitute, once for tr() to pick the right translation; the benefit
is compile time checks.


It can't be the former: tr() needs to see the string that got extracted
for translation, in order to look it up in the translation database;
it's not supposed to see what you get after you did arbitrary
replacements in it.

It could be vformat, but that's clumsy. We'll probably have a front-end like

  trFormat(std::format_string<Args...>, Args &&...)

I'm not sure what you mean here. We could entertain a trFormat()
function that does the translation _and_ the formatting in one go,
basically as a generalization/replacement of tr("...", n).arg(x, y).

I think that's the idea.

Since formatting for plain `int` is already taken, like you said, we
will have to wrap `n` into a custom type of ours, and this will give us
a lot of freedom in how to define the formatting options in a way that
the translator can understand which argument identifies the plural:

It can be a simple class enum.

namespace Qt {
     enum class Cardinality : qint64 {};
}

trFormat("{} bought {:N} apple(s)", user, QTrQuantity(n));

trFormat("{} bought {:N} apples(s)", user, Qt::Cardinality(n));

Name TBD of course.

This form can do compile-time checks on the passed arguments.

Indeed and we can force the formatter for the cardinality type to require the
"N" or "n" in the formatting string. So if the user forgets, they get a
compilation error.

We may need something slightly more complex than one letter, because other
types may also have "n" and it would confuse tooling.

This is what I'm more worried about: telling the string-extraction tools that
don't really understand C++ that this is a string with plurals. I don't know
if they need to: is it acceptable for the translator to simply supply 2-5
different forms? Or does the tooling -- and this is both .ts/.qm and .po/.mo
files -- need to know that multiple forms are possible? Will Linguist allow the
translator to enter 2-5 different translations?

Maybe I'm missing something, but the tooling does all of this already: lupdate extracts all the strings in tr() calls, and linguist allows me to add several translated forms, depending on the target language (for Italian: singular/plural; for Polish: singular, paucal, plural...).

What do we need to change here exactly?




trFormat("{} bought {:N, the amount of apples purchased} apple(s)", user,
QTrQuantity(n));
We could even support int-based formatting options for the quantity, but
I'm not really sure if that's necessary; has anyone ever requested the
quantity to be printed in another base, or with padding 0s or so? Of
course, we need to weigh the flexibility against the possibility that
someone modifies these padding options or comments without realizing
that that's changing the translation DB (!).

That goes back to the discussion on whether translators should be allowed to
change the formatting options. For numbers, the one thing that may make sense
to change is the L (locale) flag. I don't know how languages with different
number formats usually do this, but do they prefer their native digits for
some sentences and the Latin ones for some others (likely technical)?

I'm actually thinking that we may be missing a use case: tr() can be called with a string that does NOT contain %n. In this case, the quantity parameter is only used to look up which plural form to translate to; the developer can then use e.g. arg() replacements, and with those, manage localization, precision and what not:

tr("You bought a total of %L1 apple(s)", n).arg(n) // localized and pluralized

We likely need to find a way to support this as well?


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence

Attachment: smime.p7s
Description: Firma crittografica S/MIME

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to