Language issue in RC3f - default language selection with fix

[geraint]

Hi guys - thanks for the great work.  Its looking really good.

I have been experimenting with the multi-language part of the system and encountered a problem. 

When editing a product/category etc. you get the language dropdown at the top of the page but no language has been selected.  So the first one alphabetically is 'assumed' to be the default and to get the translations message to appear you must select a different language and then go back to the first.  You can test this by using a language with a language code earlier in the alphabet than english e.g. Welsh (cy-GB).

The problem is in shopfunctions.pgp at line 131-133 the $params->get("site") method returns a string in the form "en_gb" but the lagnuages from $languages = JLanguageHelper::createLanguageList($lang, constant('JPATH_SITE'), true); are in the form "en-GB" so they won't match in the select.genericlist call.

Hope this explanation makes sense

[geraint]

Also on the subject of multi-language functionality.  Should the #__virtuemart_customs table also have language specific field tables?

I notice that the frontend passes the fields values (e.g. title) through JText::_( ) which allows for localisation but not in the backend.

I'm guessing this is an oversight?

[jjk]

Oh!..., some help from a Joomfish! team member. Welcome any time   

[Milbo]

Hello geraint,

good points. Getting the right language tag is quite nasty, there are so many possibilities that it took sometime to find the right one and makes it easy to overlook something.

We found out that it is a nice feature to pass gui elements through the filter. We translate only the dynamic content (at least that is the idea).

[Studio 42]

Hi guys - thanks for the great work.  Its looking really good.

I have been experimenting with the multi-language part of the system and encountered a problem. 

When editing a product/category etc. you get the language dropdown at the top of the page but no language has been selected.  So the first one alphabetically is 'assumed' to be the default and to get the translations message to appear you must select a different language and then go back to the first.  You can test this by using a language with a language code earlier in the alphabet than english e.g. Welsh (cy-GB).

The problem is in shopfunctions.pgp at line 131-133 the $params->get("site") method returns a string in the form "en_gb" but the lagnuages from $languages = JLanguageHelper::createLanguageList($lang, constant('JPATH_SITE'), true); are in the form "en-GB" so they won't match in the select.genericlist call.

Hope this explanation makes sense

Hi,

the en-GB are transmited in the translate "view",
is converted by the function (lower + "-" to "_"),
paste in the translate controller and
if he find a valid table/view,
  paste the table fields to the json
  and a loop rewrite all fields with the conresponding fields(minus ID)

[geraint]

good points. Getting the right language tag is quite nasty, there are so many possibilities that it took sometime to find the right one and makes it easy to overlook something.

We found out that it is a nice feature to pass gui elements through the filter. We translate only the dynamic content (at least that is the idea).

I've been working on Joomfish for Joomla 1.7 and think that your native approach is the best way to deal with a multi-lingual store - it will be faster than Joomfish and a lot better than the language handling of 'content' in J1.7 where there is no relationship between original and translation.

We are planning to implement an API to allow for translations to be generated in Joomfish but stored in a component specific way i.e. in your language tables.  This would allow store managers to assign translators to translate their products, content, menus etc. using Joomfish without giving too many permissions within Virtuemart.

[Studio 42]

Nice you agree the logic.
I do the proposal to the French joomla translator but they said it's to many work to add it in joomla and give more work for developper.

We don't think this approach give many work for dev's but if you do a specific component to use it that way i think this can be a good idea.

The great advantage( if you don't use falldown to native Lang) it's that speed are exactly same for native or translated language and it's use only a simple Join

After some test we don't see a speed decrease with multi- language  and old simple language .