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));
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
smime.p7s
Description: Firma crittografica S/MIME
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
