Hi,

Thanks for summarizing my very thoughts.


Il 24/10/24 13:23, Volker Hilsheimer via Development ha scritto:
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.



With the latter, we get no compile time services from std::format, but
don’t have to pass the value twice. Use tr()’s plural functionality and
%n for it as before. Otherwise, both sources and translations can muck
around with std::format-features as much as they like (it’s equivalent
to tr(…).arg()).

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).

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:

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

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

We can pick any syntax, really:

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 (!).

I completely agree with the idea that we should not diverge in any way or form from std::format semantics, including possible extensions (like f-strings, just proposed in https://wg21.link/p3412r0 ).

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