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;
Macieira
Sent: Thursday, October 24, 2024 7:58 PM
To: development@qt-project.org
Subject: Re: [Development] format-like tr()
On Thursday 24 October 2024 10:12:35 Pacific Daylight Time Thiago Macieira
wrote:
> > IMO, we could benefit from the new syntax, if we could build our
> > imp
Il 25/10/24 10:03, David C. Partridge ha scritto:
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
One would be the compile-time check on the format strings and its
replaceme
Il 24/10/24 19:04, Edward Welbourne ha scritto:
Given that that does also substitute the relevant number into the
string, I offer:
tr("The apple(s) you bought cost %L1", n).arg(price);
where the number controlling the singular/plural choice isn't inserted
into the result, but something else
tions for those types should have certain getters...
--
Ivan
From: Development on behalf of Thiago
Macieira
Sent: Thursday, October 24, 2024 7:12 PM
To: development@qt-project.org; Nicolas Fella
Subject: Re: [Development] forma
Il 24/10/24 18:23, Thiago Macieira ha scritto:
On Thursday 24 October 2024 05:19:45 Pacific Daylight Time Giuseppe D'Angelo
via Development wrote:
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
pment@qt-project.org; Nicolas Fella
Subject: Re: [Development] format-like tr()
On Thursday 24 October 2024 03:22:55 Pacific Daylight Time Ivan Solovev via
Development wrote:
> > Unfortunately, I think we'll need the entire parsing and
> > constructing done from scratch.
>
On Thursday 24 October 2024 09:54:43 Pacific Daylight Time Giuseppe D'Angelo
via Development wrote:
> > This is what I'm more worried about: telling the string-extraction tools
> > that don't really understand C++ that this is a string with plurals. I
> > don't know if they need to: is it acceptab
On Thursday 24 October 2024 04:11:13 Pacific Daylight Time Mårten Nordheim via
Development wrote:
> (When I was still poking at QStringFormatter I was doing named arguments,
> but implemented as a templated struct you could pass in as a 'special'
> argument. e.g., QStringFormatter("{a:L}").arg(QSt
On Thursday 24 October 2024 10:12:35 Pacific Daylight Time Thiago Macieira
wrote:
> > 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'm
Giuseppe D'Angelo (24 October 2024 18:54) wrote:
> I'm actually thinking that we may be missing a use case: tr() can be
> called with a string that does NOT contain %n. In this case, the
> quantity parameter is only used to look up which plural form to
> translate to; the developer can then use e.g
On Thursday 24 October 2024 03:22:55 Pacific Daylight Time Ivan Solovev via
Development wrote:
> > Unfortunately, I think we'll need the entire parsing and constructing done
> > from scratch.
>
> IMO, we could benefit from the new syntax, if we could build our
> implementation on top of what the
On Thursday 24 October 2024 05:19:45 Pacific Daylight Time Giuseppe D'Angelo
via Development wrote:
> > 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, o
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 fo
> On 24 Oct 2024, at 12:29, Ivan Solovev wrote:
>
> Hi Volker,
>
>> From my understanding, the idea behind the std::format framework would be
>> to have a “cardinality" type for which we can implement a special formatter,
>> allowing “whatever” to be in the format specification.
>
> True, but t
schaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
From: Development on behalf of Volker
Hilsheimer via Development
Sent: Thursday, October 24, 2024 9:43 AM
To: Macieira, Thiago; development@qt-project.org
Cc: albert astals cid; Volker K
Hello!
I'm not sure {n} is great, it would clash with any potential name-matching.
If we anyway keep the formatting specification in the string then it would make
more sense to keep it in there. E.g. "{:#}" or something similar.
If the translation moves the {...} into a different order they would
ny
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
> On 23 Oct 2024, at 22:55, Thiago Macieira wrote:
>>> 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
On Wednesday 23 October 2024 05:18:20 Pacific Daylight Time Mathias Hasselmann
via Development wrote:
> std::format a field of permanent improvement, for instance we've got
> compile-time format-string parsing with C++20.
Which has low value for us. For the case of debugging, it's a meh. For
tra
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
Am 23.10.2024 um 11:22 schrieb Ivan Solovev via Development:
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?
For my patc
On Tue, Oct 22, 2024 at 10:58:59AM -0700, Thiago Macieira wrote:
Before anything, is anyone aware of research in this area?
https://lists.qt-project.org/pipermail/development/2017-May/029931.html
ff.
https://mail.kde.org/pipermail/kde-core-devel/2011-June/070319.html
https://mail.kde.org/piper
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?
For my patches that add std::format support to QByteArray(View),
I implement
24 matches
Mail list logo
