ParaView Internationalization

Development
1

Hello everyone,

I am currently working on making the ParaView UI translatable. As such, this thread is meant to be a progress update and a forum for your advice!

Objectives

The scope of this internationalization is to make all translatable strings visible in the base ParaView UI, and let developers translate their plugins and make an easy-to-use community translation workflow. Translations will be made from an online crowd-translation CMS, but we have yet to decide which one to use.

Non-romance languages should, of course, be available, as I will use the most the tools Qt5 has to offer, from build-in method to translation manager utilities.

Debug messages and logs will not be translated for now.

String refactoring

I have done a long (and I hope exhaustive) refactoring of strings in the ParaView sources, framing every relevant string inside the tr() method so that Qt searches for a translation in the user language.

New string good practices

The new proposed good practices would be:

  • Strings to be translated should be translated at declaration ! There should not be any tr() around QString variables. Strings with .arg() are valid.

  • When inside a QObject-derived class that has the Q_OBJECT macro; literal strings should be placed inside the tr() static method.

  • Otherwise strings should be in the QCoreApplication::translate(), with the context argument being the containing class or the containing file if outside of any class.

Implementation progress and concerns

I have used the handy CMake macros of Qt to make Qt generate translation source files (.ts) from source files, subsequently compiling them into a single binary, which I made ParaView load and use.

I have not yet seriously looked into the translations of PV XML files. One solution would be to extract relevant strings using a utility, add them in a cpp header and then let Qt’s lupdate add them to translations.

It has not yet been determined if the translation will be directly included in the ParaView binary release.

Open questions:

I don’t know if we should use the machine locale to translate at PV startup or leave PV in English at first, and if we should have a rollout menu with available languages or ask users for a translation file with a File Dialog?

Should the .ts translation file be put inside ParaView source or in another repository (like Slicer does)?

And if they are outside of PV sources, should I create a CMAKE variable specifying the ts’ path?

I would love to have your opinions on it!

Conclusion

If you would like to get involved, you can check my string refactoring MR and my CMake translation file generation MR - combining both gives a mostly translatable UI!

For any questions or comments, feel free to reply!

Kind regards,

Nicolas

3 Likes
2

Good effort!

I would suggest leaving the UI in English and letting the user select from a drop-down list containing country flag images, so that it is clear which language translations are available and that a country/language combination can be picked.

1 Like
3

I just merged my string refactor into master !

2 Likes
4

I agree with this too. As long as we don’t have a wizard installer where one can choose the language this seems the more appropriate solution, though it may slightly increase the size of the release.

If you have some update on that please let us know ! I think what would be very cool to have is the translation of the help for each filters/readers (this help is generated using the XML file).

5

Countries are not languages and flags are bad for that. For example, what language does the Indian flag represent? There are 22 languages officially recognized across the country. I suggest just having a list like:

  • Français (fr-FR; French)
  • Nederland (nl-NL; Dutch)
  • American English (en-US; English)
  • British English (en-UK; English)
  • हिन्दी (hi-IN; Hindi)

with some common formatting in the list.

2 Likes
6

@ben.boeckel I should have been more specific.

I meant that a flag icon should be shown next to the language name (text) and listed alphabetically as opposed to writing (fr-Fr), (fr-Ca) etc. I thought the “country/language combination” comment would make that clear.

7

This may be possible.

8

@timothee.chabat I have an experimental python utility that parses XML labels - or create label from names the same way PV does; and from that generates a C++ header file that lupdate can parse.

I could then tr-ify the GetXMLLabel() calls in PV code in order to find the label translations

1 Like
9

I am working on the CMake integration system

I will also have to do refactor in the Qt folder of ParaView and in the XRInterface plugin because some conditions uses text labels. If you find occurences of this and you don’t want to fix it yourself, please add it at the end of the issue.

1 Like
10

Hello there,

All MRs have been merged, you can now generate translations source files with the ParaView build system, and load translations binary files from the ParaView settings.

This is completed with paraview-translations, the official ParaView translations repository, containing the template ts files and soon translations in other languages.

All of the translations process and good practices are documented at this page and will be available later in the nightly documentation.

Kind regards,

Nicolas

4 Likes
11

Well done!

1 Like
12

That’s fantastic Nicolas! I put a lot of effort into adapting VTK and Paraview to use utf-8 everywhere, across all platforms, as a prerequisite to internationalisation (note the “s”) :slight_smile: but I didn’t have time to work on the implementation so I’m glad someone took the initiative.

I wonder if anyone at Kitware will be tracking the number of downloads from countries where English is not the first language as more translation files are added.

2 Likes