[PyQt] pylupdate5: qml: Parse error in UI file

Sylvia van Os iamsylvie at openmailbox.org
Wed Apr 12 11:24:16 BST 2017



On 10/04/17 20:35, Hans-Peter Jansen wrote:
> On Montag, 10. April 2017 17:07:02 Sylvia van Os wrote:
>> On 02/04/17 17:09, Sylvia van Os wrote:
>>> On 02/04/17 13:24, Hans-Peter Jansen wrote:
>>>> On Sonntag, 2. April 2017 09:54:05 Phil Thompson wrote:
>>>>> On 2 Apr 2017, at 1:45 am, Sylvia van Os <iamsylvie at openmailbox.org>
>>>>>
>>>>> wrote:
>>>>>> Hey everyone,
>>>>>>
>>>>>> I started working on making my Python app translatable in
>>>>>> https://github.com/Pext/Pext/tree/i18n but I'm running into an
>>>>>> issue with
>>>>>> pylupdate5.
>>>>>>
>>>>>> Specifically, when inside the pext directory and running "pylupdate5
>>>>>> __main__.py qml/* -ts i18n/nl.ts" to try to create a Dutch translation
>>>>>> file in the i18n directory, I get the following error output:
>>>>>>
>>>>>> XML error: Parse error at line 1, column 1 (error occurred while
>>>>>> parsing
>>>>>> element). AboutDialog.qml: Parse error in UI file
>>>>>> XML error: Parse error at line 1, column 1 (error occurred while
>>>>>> parsing
>>>>>> element). main.qml: Parse error in UI file
>>>>>> XML error: Parse error at line 1, column 1 (error occurred while
>>>>>> parsing
>>>>>> element). ModuleData.qml: Parse error in UI file
>>>>>>
>>>>>> Would anyone have a clue why this happens? I couldn't find anything
>>>>>> online, and it doesn't seem related to the translations itself because
>>>>>> ModuleData.qml doesn't contain a single translatable string. The
>>>>>> QML also
>>>>>> loads just fine in the app itself, so the QML is definitely valid.
>>>>> pylupdate doesn't support .qml files.
>>>> @Audience: Does the QML infrastructure support i18n itself, and if
>>>> yes, does
>>>> it share the Qt i18n setup?
>>>>
>>>> @Sylvia: i18n is a hydra with many heads - I'm always astonished
>>>> about the
>>>> state of affairs in this regard, when I had to leave PyQt land.
>>>>
>>>> Pete
>>> Yes, QML supports i18n and shares the same setup, see
>>> https://doc.qt.io/qt-5/qtquick-internationalization.html#localizing-your-a
>>> pplication.
>>>
>>> If you try "lupdate-qt5 qml/* -ts i18n/nl.ts" in the pext directory of
>>> the repository I linked, you will see that all QML files do get parsed
>>> correctly.
>>>
>>> Right now, the best bet for apps like mine seems to be using pylupdate
>>> for the Python file and lupdate-qt5 for the qml files, letting them
>>> both create a different output file, and then merging them together as
>>> described on http://stackoverflow.com/a/8527556.
>> So, to anyone who may try to go this way: stop. It ends in tears. Trust me.
> Hi Sylvia, would be really nice to mention the tears' reasons..
>
> Imagine, you're the sovereign of the PyQt universe. Wouldn't you be curious
> about what kind of diseases your people are suffering from?
>
> Cheers,
> Pete
>
Using pylupdate and lupdate together is just a really bad idea as the 
tools will work against each other and will cause issues like:
- lupdate deleting the location entry for Python files as it can't find 
them, breaking Linguists' preview feature
- Either tool deleting untranslated entries and marking valid translated 
entries as obsolete or missing, because they both only understand half 
the codebase
- New translations not even being added to the file (had this happen 
with the QML)

Instead, the only reasonable way to i18n a PyQt application is to make 
sure all that should be translated is either part of Python so you can 
use pylupdate, or part of QML so you can use lupdate. If the parts you 
need to translated are split over both types of file, there is no way to 
not break the translation files whenever there is a change.

If pylupdate would also support QML this problem would be non-existent. 
Although, to be fair, it is probably pretty bad practice to have part of 
your UI in the QML and part of it in Python so this did give me a good 
reason to clean up my codebase somewhat and not being able to translate 
the CLI part as that's part of Python (think the --help flag or debug 
statements printed to the command line) is something I am willing to 
live with.

- Sylvia


More information about the PyQt mailing list