[Development] format-like tr()

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20241023/e2977d16/attachment-0001.bin>