Re: [libreoffice-l10n] Language names should be in the target language chars

A suggestion to the first point of Eike discussion: what if a centralized page like 
http://zh-cn.libreoffice.org/international-sites/  would expose a square matrix of names (actually 
49 x (1+49):
- each row will expose the link to the localized-site + the name of all languages written in the 
localized language?

The work will need to be updated each time that a new localized-siet will be added; not very often.

diego

-- 
+--------------------------------------------------------------------------------------- 
| Diego Maniacco (Südtiroler Informatik AG - Informatica Alto Adige SpA)
| Autonome Provinz Bozen - Südtirol - Provincia autonoma di Bolzano - Alto Adige
| Tel +39 0471 566 159
+--------------------------------------------------------------------------------------- 
On 15/04/2014 20:54, Rimas Kudelis wrote:


        Hi Eike, 
        
        let me disagree with you. The points you mentioned are valid, but to me they look more like 
a bunch of selected edge cases than common real-life scenarios. 
        
        2014.04.14 15:03, Eike Rathke wrote: 
        

                On Thursday, 2014-04-10 18:26:44 +0800, 锁琨珑 wrote: 
                
                

                        So far, the language names shown in "Tools - Options - Language 
                        Settings" are in the localed language name strings. 
                        
                        I believe those language names should be changed to the target names 
                        chars for all UIs, like the language listed here: 
                        http://zh-cn.libreoffice.org/international-sites/ 
                        (see the second column) 
                        

                While having language names in their native language is fine for 
                interfaces where a user only wants to pick his/her own language, it is 
                not desirable for interfaces where several languages can be chosen for 
                different purposes that are not native to the user. Let me explain some 
                disadvantages: 
                
                * a document containing language attribution the user doesn't know the 
                   native name of, s/he will see a meaningless entry in the language list 
                


        If the user doesn't know the language in question, knowing the name of that particular 
language in their own language will hardly help. In other words, I doubt that actually knowing that 
the language is Whateverian (something you've never heard of) will help you understand the doc any 
better than knowing that the language is Gibberishian (the name you can't even read). 
        
        

                * seeing the language list, a user will not know what languages are 
                   offered except those s/he can somehow deduce 
                


        The user doesn't really care about "what languages are offered". What they care about is 
whether or not the language they need *at the moment* is offered. Assuming that they will know the 
native name of that language, it will often be much easier for them to find that name than guess 
it. Would you know or guess that German in Lithuanian is Vokiečių? I doubt that. 
        
        

                * wanting to prepare a document with different locale settings (e.g. 
                   using different currencies or formatting) the user would have to know 
                   the native names 
                


        I doubt one could prepare a document in any language they don't know to such extent. 
Setting metadata would be my least concern in such case... 
        
        

                * a developer adding a language to the language listbox would have to 
                   know that name in the native language; yes, CLDR in the mean time 
                   provides native names of most frequently used languages, but not for 
                   the not so frequently used that now are occasionally requested; s/he'd 
                   have to take the word of the one requesting that language 
                


        How's that a problem? If somebody makes a request, you can always ask the requester what 
the native language name is. 
        
        

                * for developers this gets even more cumbersome for languages that can 
                   be written in different scripts, or scripts the developer doesn't know 
                   at all; would you know how to correctly write Arabic and enter it on 
                   your native keyboard? Or Mongolian in the Mongolian script? You'd have 
                   to rely on copy&paste and pray that your editor handles all Unicode 
                   characters, RTL writing direction and so forth. 
                


        I agree that this might be a bit inconvenient for developers, but I'm pretty sure there 
must be an acceptable solution to that inconvenience. For example, non-latin language names could 
probably be stored in escaped fashion where appropriate (in the source code). I really don't think 
"X is inconvenient for developers" is a good excuse to keep something at a state less convenient 
for the end-user. 
        
        

                        I am thinking about this because of the following reason: 
                        
                           * It's a waste of time for localizers to translate every foreign 
                             language names to their own locale. Even translated, it may not be 
                             correct. 
                        

                That's about 350 language names we currently have, of an overall of some 
                hundred thousand words to translate (including help), doesn't really 
                look significant to me. Plus, once translated the names almost never 
                change. 
                


        It's still useless and – most importantly – inconvenient to most users (=those who know the 
native name of language they want to pick). 
        
        

                           * In case the users are trying to switch between languages, there may 
                             be confusion (for example, if I want to test something in Franch UI, 
                             and after that I want to change back to Chinese UI it's really 
                             difficult to find the right one in the list box. 
                        

                There's an easy trick for that: assign the language to a portion of text 
                and reload the document in the other UI language. 
                


        I'm pretty sure that developers can find easy tricks to solve their inconveniences as well. 
E.g. copy-paste. 
        
        

                        And there is a corrensponding bug report here: 
                        Bug 59901 - UI: Name of each language in target language 
                        https://www.libreoffice.org/bugzilla/show_bug.cgi?id=59901 
                        

                I'll add the same comment there. 
                


        I hope your stance is not too strict about this. 
        
        Regards, 
        Rimas 
        
        



-- 
To unsubscribe e-mail to: l10n+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted