> 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