Installing from official .msi downloaded from www.libreoffice.org on a non-English Micrsoft Windows (French in my case). Choose "custom installation". In the screen where one can select which components to install, these components are sorted according to their *English* name, not according to their localised (displayed) name. That makes it difficult to find a particular entry and/or makes the user think this entry is not available. That is particularly striking for UI languages (because there are many of those): "Coréen" (Korean) is lost in a sea of K* "Gallois" (Welsh) is nearly at end of list (near Xhosa), instead of among the other G* They should be sorted according to their displayed name. As a second choice (if locale-dependent sort is too difficult), display the ISO code for the language, with the user-friendly (localised) name in parentheses, and sort according to the ISO code. Which ISO code? I'd say ISO 639-2/T rather than ISO-639-2/B; we might want to use ISO-639-1 codes for languages that have them. E.g. in an English install: ara (Arabic) ... cym (Welsh) ... fra (French) ... kor (Korean) ... In a French install: ara (Arabe) ... cym (Gallois) ... fra (Français) ... kor (Coréen) ... In a Dutch install: ara (Arabisch) ... cym (Gallisch) ... fra (Frans) ... kor (Koreaans) ... This makes the sort key evident. Compare to the current situation: In an English install: Arabic ... French ... Korean ... Welsh ... In a French install: Arabe ... Français ... Coréen ... Gallois ...
I don't know how to fix it in the current framework, i.e. in multi-language MSI, because MSI uses internal transform files to localize the English strings, thus the original English sort order is preserved. BTW it was an improvement to sort in English order, it was originally sorted by IDs. :-P Hints or patches are welcome.
(In reply to comment #1) > I don't know how to fix it in the current framework, i.e. in multi-language > MSI, because MSI uses internal transform files to localize the English strings, > thus the original English sort order is preserved. BTW it was an improvement to > sort in English order, it was originally sorted by IDs. :-P Well, my second (fall-back) suggestion was "sort by ID" *but* *show* the ID. I was also suggesting to make the shown ID the appropriate ISO code, as in: deu (German) fra (French) por (Portuguese) Or if we prefer two-letter codes (when available): de (German) fr (French) pt (Portuguese)
Created attachment 57394 [details] partial untested patch Untested, but showing the idea. Also have to fix the sorting order, not sure where it is decided.
In scp2 definition files all entries have a Sortkey property. For language packs and dictionaries this was overriden. See commit f34252f6. Using 2 or 3 letter ISO codes looks scary to me. Do you think that an average user knows the ISO code of his/her language? I wish if it could be solved in the installer somehow, with a bit more clever controls, that sort lists automatically.
(In reply to comment #4) > Using 2 or 3 letter ISO codes looks scary to me. Do you think that an average > user knows the ISO code of his/her language? Not necessarily, but then (s)he is *still* better off than in the current situation. Let's take the example of a French/Korean bilingual person that uses a French language Windows. Thus the install UI is in French. French UI/helppack is checked by default, so the user wants to add Korean (his mother also uses this computer, and she doesn't speak French that well: recent immigration). Current situation: - Worst case: The user takes a cursory glance at list of languages. Looks sorted. Jumps to general area of where the searched language should be (all the languages that start with "c"), don't find it there. Sorry ma, no Korean support. Learn French or ask your brother to mail you a copy of ${COMPETITOR} that he buys for you in Korea. - Best case: *Maybe* the user notices they are not quite sorted, there are exceptions. So (s)he reads the whole list until finds "Coréen" among many other 'K*'. Checks "Coréen" and is on hir way. - Geek/developer case: *Maybe* the user notices they are not quite sorted. Had the same problem in a program (s)he develops so thinks "oh, they are probably sorted by ISO code or English name", let's look in these places. Finds "Coréen" quickly, checks it abnd is on hir way. Situation as I suggest: - Worst case: The user sees a bunch of cryptic codes and right next to them a localised name. Assumes they are sorted by code because the code comes at the beginning and that's how *everything* text is sorted: first according the the first letter, in case of equality according to next letter and then lather, rinse, repeat. Non-geeky user has *no* other notion of sort for text (strings). So resorts to reading the whole list until finds "Coréen" and is on hir way. - Best case: user knows (or "guesses") ISO code. Sees sorted by ISO code, jumps to general area, finds it quickly, confirms by the localised full language name guessed ISO code is correct and is on hir way. - Geek case: see "best case". Compare the "worst case" in the two scenarios. The worst case in my scenario is the best case in current situation. "Worst case" of current situation is avoided altogether. Besides, 2-letter ISO codes "often" match the country code of the country that gave its name to the language (if any). Users usually know that: it is the Internet country-code top-level domain. The 2-letter and 3-letter "T" variant has the advantage of being usually chosen to resemble the (Latin transliteration of the) language's name in itself: e.g. "fra" for French (Français), "deu" for German (Deutsch), sqi for Albanian (shqipe), cym for Welsh (Cymraeg) ... > I wish if it could be solved in the installer somehow, with a bit more clever > controls, that sort lists automatically. Yes, that would be the first choice.
Just found, that if we sent a TVM_SORTCHILDREN message to the specified parent item in a tree-view control, then it would be sorted. See http://msdn.microsoft.com/en-us/library/windows/desktop/bb773782%28v=vs.85%29.aspx
Although Microsoft says that SelectionTree control can publish a control event only on Windows Server 2003 and above, the custom action seems to be working under a fully patched Windows XP SP3. Maybe it fails silently on older Windows XPs, not to mention Windows 2000. I did not test those.
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=39bb77fd667f9d9fdaf374f3934b6eec7b7dc57a fdo#46355 sort SelectionTree control of Custom Setup with a custom action
Andras Timar committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f12ab92d1d404ac72c011587b7b73b89c69d7b38&g=libreoffice-3-5 fdo#46355 sort SelectionTree control of Custom Setup with a custom action It will be available in LibreOffice 3.5.4.
*** Bug 50376 has been marked as a duplicate of this bug. ***