[Development] QtCS2019 Notes: Clang-based cpp parser for lupdate

[Kai Köhne]

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Joerg Bornemann
> Sent: Friday, November 22, 2019 1:25 PM
> To: Kai Pastor, DG0YT <dg0yt at darc.de>; development at qt-project.org
> Subject: Re: [Development] QtCS2019 Notes: Clang-based cpp parser for
> lupdate
> 
> On 11/22/19 7:21 AM, Kai Pastor, DG0YT wrote:
> > Am 21.11.19 um 20:23 schrieb André Pönitz:
> >> On Thu, Nov 21, 2019 at 07:48:41PM +0100, Oswald Buddenhagen wrote:
> >>> a more radical and much simpler approach would be switching to
> >>> gettext
> >> The most prominent difference is the (usually) per-class automatic
> >> context which I always found too clever to be sensible, and that's
> >> effectively also the only reason to need a C++ parser.
> >
> > Indeed, while 'context' is a useful concept, the (implementation)
> > class name often isn't the best 'context' from a more general point of
> > view (features, human translators, screenshots). And if a class does
> > not inherit from QObject, the context already needs to be declared
> explicitly.
> >
> > Given the Qt Creator example, would it be feasible to make explicit
> > declaration of a file's context mandatory, at least for the existing
> > ("fast") parser? If not mandatory, an explicit declaration could at
> > least disable all automatic detection for the rest of the file, making
> > it possible to use modern C++ without surprises.
> >
> > Maybe this could be complemented by a lconvert feature to rename a
> > context in an existing ts-file, for those who want to move away from
> > class names as contexts.
> 
> That's certainly a possibility. With an explicit context declaration (that's easy
> to detect) on file level we can use an even simpler parser/extractor that
> doesn't have to know much C++ at all.

Keep in mind that you need this context available both at runtime and 
at lupdate time. That is, the only setup how this IMO would reliably work 
is if  we make the context a part of the tr() call - effectively calling 
QCoreApplication::translate(context, string). This is already possible right 
now.

> On the topic of switching to gettext:
> 
> It would be cool to know where this was discussed before. My searches
> yielded nothing.

I remember having a meeting about that in the Trolltech office 2008, 
weren't you there? 😉

> It's tempting to switch to an established solution.
> Of course we must make sure that gettext is properly supported on all target
> platforms. It seems to be available via vcpkg on Windows at least.
> 
> There needs to be a migration path if we want to use gettext as the
> recommended i18n solution for Qt users (and maybe deprecate the
> lupdate/lrelease). We could provide a migration tool, based on lupdate's
> current parser, that transforms tr("foo") calls to _("foo"). Of course, that gets
> more complicated due to the mentioned context differences.
> And Linguist should probably be able to edit .po files.

Well, if people want to use gettext they can already do so now. But switching to 
gettext is a source incompatible change, so even with 'porting' tooling I don't think 
we can remove lupdate  / tr() any time soon.

Regards

kai