translations are unsorted in Windows installer

Bug #1654460 reported by uwestoehr
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Low
Patrick Storz

Bug Description

In the Windows installer for 0.92 it is very hard to find e.g. the language Spanish in the list of translations to be installed.

The reason is that the languages are not sorted with their names. I see now that they are sorted by their two letter code. This is not only intuitive, I bet the vast majority doesn't know that languages have such a code nor what the code for the language is. I mean when I want to have e.g. Armenian, I look under "a" in the list and don't have the idea to scroll down to "hy" because this is its language code.

jazzynico (jazzynico)
tags: added: packaging win32 win64
Changed in inkscape:
importance: Undecided → Low
Revision history for this message
Patrick Storz (ede123) wrote :

### WiX
For the MSI installer this could be "hardcoded" as we do not currently support localization and the sort order would always be the same.

--------------

### NSIS
For the EXE installer this is not something we can fix that easily as the displayed language names change between locales and therefore we have to update the sort order depending on the selected installer language on-the-fly.

There seem to be possibilities, though, see [1] (apparently requested by theAdib a long time ago to fix exactly this issue :-D ), however it could easily cause more serious issues if the sorting fails for whatever reason (the code to generate the language sections in the NSIS installer is already quite complex).

Revision history for this message
Patrick Storz (ede123) wrote :

(sorry, forgot something and the stupid Launchpad does not allow editing)

[1] http://nsis.sourceforge.net/Sorting_Components

Revision history for this message
uwestoehr (uwestoehr) wrote :

I am the author of the NSIS installer for the program LyX (lyx.org). In it I have the same task: I have several language dictionaries and need to sort them. I used always the English names, independent on the chosen installer language because everybody knows the English name of his language.

Doing this is not difficult: Here is the part of my NSIS code that does this:

#--------------------------------
# visible installer sections

Section "!${APP_NAME}" SecCore
 SectionIn RO
 !if ${SETUPTYPE} == BUNDLE
  # if no TeX was found MiKTeX will be installed which requires space
  !if $PathLaTeX == ""
   AddSize 1020000 # size in KB
  !endif
 !endif
SectionEnd

Section "$(SecFileAssocTitle)" SecFileAssoc
 StrCpy $CreateFileAssociations "true"
SectionEnd

Section "$(SecDesktopTitle)" SecDesktop
 StrCpy $CreateDesktopIcon "true"
SectionEnd

# Expand the list of dictionaries by default as this was requested by several
# users. For the thesaurus this is was not requested because this section
# is by default empty.
SectionGroup /e "Dictionaries" SecDictionaries

Section /o "Afrikaans" SecDAfrikaans
 StrCpy $DictCodes "af_ZA,$DictCodes"
 AddSize 1440
SectionEnd

Section /o "Arabic" SecDArabic
 StrCpy $DictCodes "ar_DZ,$DictCodes"
 AddSize 2500
SectionEnd

Section /o "Armenian" SecDArmenian
 StrCpy $DictCodes "hy_AM,$DictCodes"
 AddSize 2000
SectionEnd

Section /o "Bahasa Indonesia" SecDIndonesian
 StrCpy $DictCodes "id_ID,$DictCodes"
 AddSize 217
SectionEnd

Section /o "Bahasa Melayu" SecDMalayan
 StrCpy $DictCodes "ms_MY,$DictCodes"
 AddSize 227
SectionEnd

Section /o "Belarusian" SecDBelarusian
 StrCpy $DictCodes "be_BY,$DictCodes"
 AddSize 1730
SectionEnd

Section /o "Brezhoneg" SecDBreton
 StrCpy $DictCodes "br_FR,$DictCodes"
 AddSize 5510
SectionEnd

...

Revision history for this message
Patrick Storz (ede123) wrote :

Dropping localized language names and simply sorting by English language name would work... but do we want that (it certainly defeats the idea behind a localized installer)?

We could use a compromise and use names like "German / Deutsch".

If you have a look a the relevant NSIS script that is used in Inkscape [1] you'll see that it's a "little" bit more complex than what seems to be used in LyX. I guess with that in mind you'll agree that consistent sorting is not as simple as re-ordering some sections...

[1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/view/head:/packaging/win32/inkscape.nsi#L543

Revision history for this message
Patrick Storz (ede123) wrote :

I've implemented sorting for NSIS, but I'm still a bit hesitant to commit as there are two pitfalls I can think of:

1. We have to ensure that dialects are grouped together. By sorting language codes (as we do now) this is always given. However if we start to sort by translated language name we could end up with "Deutsch" and "Schweizerdeutsch") (just as an illustrating example) ending up in totally different positions. We'd therefore have to make sure all translators stick to a scheme like "Deutsch (Schweiz)".

2. If we have partial translations sorting will fail altogether as the user won't know whether to search for the translated or English language name. Much worse than what we have now!

I really don't like this solution in those (not too uncommon) cases and I'm really wondering if language codes are that unknown to people? Cause in my (maybe "non-standard") mind sorting by language code is really universal and will always allow people to find the language they're searching (no matter wether it's translated or not).

Thoughts?

Revision history for this message
Hachmann (marenhachmann) wrote :

I wouldn't even have guessed that a list of languages that is translated for my language is ordered by a hidden ordering (i.e. the language code).

Unless maybe, it could be done like:

Deutsch (de)
.
.
.
Armenisch (hy)
...

then it would be easy to see for people that there is something else involved in the sorting. That doesn't mean they'll quickly find what they're looking for, though.

I agree, people are probably more likely to know their language's English equivalent than their language's two-letter code.

Revision history for this message
Patrick Storz (ede123) wrote :

> Unless maybe, it could be done like:
That's exactly like it's done currently ;-)

I thought some more about it in the meantime and had a "crazy" idea: We could automate the whole thing!
By extracting language translations from the .po files we safe translators some effort and facilitate keeping translations up-to-date. This would (hopefully) resolve most of pitfall 2. At the same time we'd even remove the need to update the installer scripts when a new language is added!

Seeing that we order languages in Inkscape preferences the same way (alphabetically by translated language name) we would at least be on par. As we typically use strings like "English/Australia (en_AU)" in the .po this would also solve pitfall 1.

I'll see if I can get something done tomorrow...

Revision history for this message
Patrick Storz (ede123) wrote :

Done:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15319
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15418

Translated language names can now be automatically extracted from the Inkscape .po files.

Installer translations (in both .msi and .exe installer) are sorted by language name rather than by language code.

I attached a "dummy installer" (without any actual content) so you check if everything works as intended if you like.

Changed in inkscape:
assignee: nobody → Eduard Braun (eduard-braun2)
status: New → Fix Committed
Revision history for this message
Hachmann (marenhachmann) wrote :

> That's exactly like it's done currently ;-)

Ah, sorry, I inferred (wrongly) from what I read.

Your automation fix sounds (and looks) cool :)

Revision history for this message
Qantas94Heavy (qantas94heavy) wrote :

Fix released with Inkscape 0.92.1.

Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.