Hi :) I really like that link and it works well for just English. I thought LibreOffice got translated into many more languages? Do other languages happen to have a similar page already or is that only on the English site?
I suspect that not all teams have enough people or time to get all that website done too and have been heroic enough. Getting the whole of LibreOffice translated is an immense amount of work and i think many people appreciate it but never get around to saying so. Good work all and many thanks from a lurker! :D Even 49 x (49 + 1) seems like quite a lot but if it needed to go to a couple of hundred that might be really difficult, even though it mostly only needs to be done once. Is it worth it? Of course i would say yes but then i am not one of the people doing the work and i have no idea just how much work it would be. From what at least 1 more experienced person has said i think it sounds like it might be too much work. Regards from Tom :) On 16 April 2014 10:10, Maniacco, Diego <diego.mania...@provinz.bz.it>wrote: > 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+unsubscr...@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 > -- To unsubscribe e-mail to: l10n+unsubscr...@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
