Problem with block thelang.php

Topic:	Problem with block thelang.php
johnww Freshman Posts: 36 Posted: 7.Mar 2006 - 20:40	Using pn761 The language dropdown box is driven by includes/blocks/thelang.php Depending upon the current language, the dropdown box displayed in the langauge block will differ. If the current language is english, spanish will appear "spanish", if the current language is spanish, spanish should appear "espanol". The list of languages is stored in files like: language/eng/languages.php language/spa/languages.php In my system, files like language/eng/languages.php are not being used to generate this dropdown list. In my system, the dropdown is driven by data in language/languages.php. Therefore, no matter what language is current, the list of languages displayed in the dropdown is the same. Does anyone else have the same problem?
Simon online Steering Committee Posts: 13427 Posted: 7.Mar 2006 - 21:04	Please log this in the bug tracker to ensure it gets addressed. -- Regards, Simon itbegins.co.uk - Zikula Consulting Please read the Support Guide
markwest Moderator Posts: 7720 Posted: 7.Mar 2006 - 21:35	This isn't a bug but by design - languages get represented in their localised form - languages/<lang>/languages.php isn't used at all although may exist in older language packs. To provide an example of why it's now setup this way. Say I go to a chinese/english site where chinese is the primary language. I don't read (or speak for that matter) any variant of chinese so I wouldn't recognise 'english' translated into chinese. But in the case ..760+ 'english' will always be represented as 'english' so that a native speaker of that language will always be able to get to thier translation. -Mark</lang>
Simon online Steering Committee Posts: 13427 Posted: 7.Mar 2006 - 22:04	I misunderstood the post - Mark is right, it of course makes more sense for languages to appear in their native form rather than that of the current language. -- Regards, Simon itbegins.co.uk - Zikula Consulting Please read the Support Guide
Yumi Softmore Posts: 85 Posted: 8.Mar 2006 - 04:36	As far as I understand John is that he suggests that the language name should be displayed in the native writing. To use Marks example, The Chinese may not be able to read English and does not understand that "Chinese" is what he is looking for. On the other hand, if you can not understand the local symbols for Chinese then you do not want to set your language to this anyway. So it would indeed make sense to localise the language names I did exactly what John suggested manually and it worked. But I forgot which file I edited. Michael Just discovered that I am right and wrong. Edit the file /languages/languages.php and it is possible to insert local characters. However, if you log on with a computer not set to display them, you get only ??????? which is not helpful. So Mark is right! International character set is a must.
markwest Moderator Posts: 7720 Posted: 8.Mar 2006 - 14:19	Correct - the file is set up at the moment with a latin character set localised version so that extended character set usage isn't forced upon anyone. Using my example of a chinese/english site non latin chracter encoding will be used so languages.php can be updated with the correct localised version. At the moment what we have now is better than what we had - i.e. as an english person I had to know the word for 'english' in every language in order to change the language. This has knock on effects though to the admin panel where the langauges drop down also uses the localised version putting additional work on the admin side. But if we are to have a compromise - which this is - i'd rather the usabiliy be weighted in favour of the user side than the admin side. A more complete language solution is required and one of the key tasks for PN .9x will be a full review of how we handle an ML site. This review includes language packs, translations, ML content, language selection, ecoding and just about any other ML related topic. -Mark