Some thoughts on .desktop files localization


(Evgeny Kuznetsov) #1

While making my humble commit on Github last week I couldn’t help noticing that .desktop files are left out of localization efforts. I’ve been wrapping my head around this matter ever since, and here are some thoughts I would greatly appreciate any input on.

Specification advices certain entries in .desktop are to be localestring instead of string. So additionally to the current entries like

GenericName=File synchronization

something along the lines of

GenericName[sv]=Filsynkronisering
GenericName[ru]=Синхронизация файлов

and so on would be welcome there.

My concept of what a possible solution can be:

  1. Introduce a new .html file somewhere in gui folder (not to be linked to from anywhere or otherwise used in GUI proper) that would contain all the necessary strings.
  2. Let the current translation handling facilities pick up those strings and have them translated.
  3. Have a script to (partially?) autogenerate .desktop files, somewhat similar how the AUTHORS file is being generated now. That would likely have to:
    • parse the abovementioned .html for strings to look for,
    • look up the translations in gui/default/assets/lang,
    • perform a sanity check on each line so as, for instance, not to break a .desktop file with a line containing a rogue semicolon introduced by a translator,
    • compose the required lines and write to .desktop files.

Now, please be aware that I’m not a programmer (I actually teach medicine for living), and I’ve never written a line of Go in my life. That being said, I have actually done some clumsy ad-hoc coding in JS and bash, and am actually willing to at least attempt to make this contribution and learn some Go and better programming along the way.

So here are the actual questions that prompted me to write this post before opening an issue on Github or making a messy PR:

  1. Does the plan above look sane enough, or is it really a dirty kludge? Am I missing some elegant and straightforward way to go about this matter?
  2. With the recent activity in cli development, is there not a chance of a bigger outside-of-GUI-translation thing emerging? Is my proposal sane considering that scope?

What would you say?


(Jakob Borg) #2

I’d skip the html part of it, which does seem a bit kludgy. You already know this, but to recap the current system:

  • strings in the HTML files that need translation are marked with a specific attribute (translate)
  • a (Go) script finds all of these and builds the lang-en.json containing the English translation (English -> English).
  • Transifex grabs this file, translations happen.
  • another script downloads the translations in corresponding lang-whatever.json files, and some javascript framework loads these at runtime.

For the .desktop files we could tweak the translation scripts to

  • in addition to reading html files, read .desktop files and grab some of the attributes like GenericName. These end up in lang-en.json. (this goes into scripts/translate.go somehow)
  • for each lang-xx.json, output a corresponding GenericName[xx] into the .desktop files. (this goes into scripts/transifexdl.go or into a completely separate scripts/update-desktop-translations.go)

As for translating the CLI and log output etc? Hmm. Maybe. I’m not convinced.


(Evgeny Kuznetsov) #3

Thanks! This looks like a more straightforward approach indeed.

Perhaps it’s also a good idea to move the current .desktop files elsewhere (etc/linux-desktop/stubs maybe) and use them on first step to grab lines from. Then, on last step, take them verbatim and append with translations to result in shippable .desktop files in /etc/linux-desktop?