[Development] format-like tr()

[Giuseppe D'Angelo]

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.dangelo at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20241024/f0ba9351/attachment.bin>