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

Joerg Bornemann Joerg.Bornemann at qt.io
Fri Nov 22 13:25:21 CET 2019

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.

On the topic of switching to gettext:

It would be cool to know where this was discussed before. My searches 
yielded nothing.

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.



More information about the Development mailing list