David C. Partridge (25 October 2024 10:03) wrote:
> While I applaud the thought of using std::format where appropriate, I
> can't see what converting the existing tr() mechanism to that will
> gain Qt Development or Qt Users
This needn't be about Qt converting its translations to use std::format;
it's about being able to support it, if some project using Qt chooses to.
After all, tr() takes a developer-written string and converts it to a
translator-written string selected based on the user's locale settings
and the singular/.../plural machinery. Once tr() has returned that
string, the calling code can do what it likes with it.
So while we've traditionally called .arg() on it to do formatting within
the string, there's no obvious or sensible reason why a project using Qt
shouldn't use std::format, or Qt's UTF-16-enhanced version of it, on the
resulting strings, provided their developers and translators are all on
the same page about how that works.
Given that Qt is on its way to adding std::format support, it makes
sense to support projects that chose to handle it that way. After all,
if they're using PySide or PyQt they have a richer cousin of std::format
at their disposal, which we should at least support for translations of
PySide and PyQt applications, if only because it is native and idiomatic
for python programmers. Ensuring that same support also works for C++
projects that want to use std::format follows naturally, as std::format
is presumably expected to become the native and idiomatic way to do
string formatting in C++, too.
Eddy.
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
