> Unfortunately, I think we'll need the entire parsing and constructing done
> from scratch.
To be honest, I'm not a big fan of this idea. We already have a working code
that does the translation, and we also have QString::arg() formatting.
IMO, we could benefit from the new syntax, if we could build our implementation
on top of what the standard provides for us. But I see little benefit in
reimplementing the standard from scratch.
I do understand that the standard (even in C++26) does not support formatting
into char16_t, but as you pointed out, the l10n and logging are in UTF-8
anyway.
As for me, the standard really misses the customization points for standard
formatters. But I still think that we should try to use what it provides,
instead of inventing a completely custom implementation.
> How much of std::format-related classes could you use? If
> one of the parameters is a std::chrono::duration, are you able to use the
> std::formatter?
Maybe I chose poor wording, but I only provided std::formatter specialization
for QByteArray(View), so std::chrono classes are handled by the std
implementation, nothing is changed there.
>> And I still used std::format to do the actual formatting, because I
>> didn't want to mess with width and padding on my own.
>
> For numbers, I agree. For strings, I question the usefulness.
Even for strings it's not straightforward, because not every code point has
a width of 1. It's all documented in the standard, but still an extra
complexity while implementing.
> Ok, so if we use their parser, the number must be {0} or the only, right? How
> do we communicate to translators and tooling that this a plural form?
Well, the argument id should be a non-negative integer value, yes. But we can
have our custom format string. Maybe we can have some custom character in the
beginning, and then delegate the parsing to default one. Something like:
std::format("{0:n*^10.2s}", "test");
Then the parse() method of our custom formatter will parse the first character,
check if it's 'n', and delegate the rest of the parsing to
std::formatter<std::string_view>::parse().
Didn't check if it works in practice, though.
> But you didn't answer the important part of the question: the padding and
> filling. The original string in Engineering English was {:%T}, which means no
> padding and no filling. Are the translators allowed to change it?
I do not have any experience in l10n, so I cannot answer if that's the right
thing to do or not. But from the developer's point of view it only requires
that we do the format parsing at runtime instead of compile time, doesn't it?
But we'll anyway have to do that if we allow to change the format specifiers
while doing the translations.
------------------------------
Ivan Solovev
Senior Software Engineer
The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
ivan.solo...@qt.io
www.qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
________________________________
From: Thiago Macieira
Sent: Wednesday, October 23, 2024 10:55 PM
To: development@qt-project.org; Volker Krause; albert astals cid
Cc: Ivan Solovev
Subject: Re: [Development] format-like tr()
On Wednesday 23 October 2024 02:22:51 Pacific Daylight Time Ivan Solovev via
Development wrote:
> Hi Thiago,
>
> first of all, could you please clarify, how do you see the potential
> implementation?
> Do you think that we can reuse some of the things that std::format
> provides, or do we need to write everything from scratch?
Unfortunately, I think we'll need the entire parsing and constructing done
from scratch. I hope that we can use std::format_string and some of the
harness code to handle args.
I don't think we'll need std::basic_format_string<char16_t>. The l10n'able
strings in the source code are in UTF-8, as are the messages for the logging
system.
> For my patches that add std::format support to QByteArray(View),
> I implemented a parser that is compatible with standard format specifier for
> string types, which is just a small subset of
> https://eel.is/c++draft/format.string.std
I'll take a look. How much of std::format-related classes could you use? If
one of the parameters is a std::chrono::duration, are you able to use the
std::formatter?
> And I still used std::format to do the actual formatting, because I
> didn't want to mess with width and padding on my own.
For numbers, I agree. For strings, I question the usefulness.
> > a) keep the "n" and make it mandatory, as in {n}
>
> If we use std::format, then we cannot do it, because it does the
> argument index parsing on its own, and delegates to a custom formatter
> specialization after that. And argument index can only be a non-negative
> integer value.
Ok, so if we use their parser, the number must be {0} or the only, right? How
do we communicate to translators and tooling that this a plural form?
Should we bring this to SG16 and ask for their long-term idea (C++26 or 29)?
> > That is, could they replace a "{1:%X}" time representation with
> > "{1:%H}:{1:02%M}" ?
>
> With std::format you can use the same argument index multiple times, so
> it makes sense to allow it.
I understand, but the question was for l10n: does it make sense to allow this?
If it doesn't for them, then we don't have to do. If it is easy to implement
anyway, then repetition is a moot point.
But you didn't answer the important part of the question: the padding and
filling. The original string in Engineering English was {:%T}, which means no
padding and no filling. Are the translators allowed to change it?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
