Translations
Open, LowPublic

Description

Kube needs to be prepared for translations.

We need to figure out whether we can use a Qt only solution, or whether we need ki18n.
We also need to figure out how to do translations in qml.

Once that is decided we need to make the whole codebase translatable.

cmollekopf moved this task from Backlog to 0.4 on the Kube board.Jun 28 2017, 1:59 PM
cmollekopf edited projects, added Kube (0.4); removed Kube.

We'll use QObject::tr because:

  • less dependencies
  • the ki18n QML variant is provided by kdeclerative which has all sorts of dependencies including KIO, so we end up needing the that version anyways.
  • We by design don't support translated strings from libraries, so we don't care what's used outside of kube.

See https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Systems#Writing_a_Messages.sh_script for how to extract messages.

I made all the qml strings translatable with qsTr

cmollekopf added a comment.EditedJul 19 2017, 4:53 PM

Excellent.

qsTr seems fine, we'll try that route for now.

Some extra input from the Mailinglist on what differences there are:

I am no expert on the matter but technically you do not need to use
ki18n. e.g. various frameworks are qt-only. Also, kirigami and
gcompris are AFAIK qsTr() only (i.e. no ki18n qml either). To get this
going you'll need to make sure that your Messages.sh extract a _qt
suffixed pot (e.g. foobar_qt.pot), in cmake generate a loder
(ecm_create_qm_loader) and install translations using the right macro
(ecm_install_po_files_as_qm).
Best hold on to what kirigami does I guess.

Again, no expert, but unless you find that you want a feature of ki18n
or encounter the limitations of tr() there is no real need to use
ki18n. The biggest advantage of ki18n to me is semantic markup [1]
allowing you to tag strings with a specific UI usage marker and
instead of writing richtext relying on common markup tags such as
<filename> to employ standard styling. It also has more accessible
and/or powerful catalog loading I seem to recall. But if you find that
you do not need much more than strings and plural strings and maybe
strings with numbers, Qt's translation system should get the job done
just as well.

[1] https://api.kde.org/frameworks/ki18n/html/prg_guide.html#kuit_markup

Not an expert but one thing is scriptability, which is used for example for
advanced plural handling.

Qt's plural handling only allows to specify fixed strings for certain numbers,
while scripting allows rules based on calculations.
E.g. same string for every multiple of a number or all values ending with a
certain number.

We also have a Messages.sh file by now.

cmollekopf edited projects, added Kube (0.5); removed Kube (0.4).Aug 20 2017, 3:10 AM

No further plans for 0.4 I think.

cmollekopf lowered the priority of this task from Normal to Low.Sep 13 2017, 10:57 AM
cmollekopf edited projects, added Kube; removed Kube (0.5).Jan 10 2018, 12:05 PM