Re: [jcms] Fallback language..

[Ove]

Hi Marco,

I'm not involved in the Cms development but try to use as much of the API as possible.

We should have 3.0.2 as a basis for comments on multilanguage. First a thx to Benjamin Trenkle for the item associations in this version.

See also "Questions about the xxxxx_associations table. Uses, and where it happens?" in this group and the link
 http://community.joomla.org/blogs/community/1695-multilanguage-in-302-whats-new.html

You're right about the "default" links.  I'm not that far to make a suggestion.yet. To bring the user back to a tranlsated menu item or even the language home when changing language is perhaps not the best way. That said I know it's not that easy to find a general solution in nested trees and the same item in many places.


Ove

Marco Dings skrev 10.12.2012 00:14:

I've had the "pleasure" of doing several multilingual sites which i ended up supporting
with a 3rd party extension to make things "practical". There are a few, like Josetta and KMFastrans.
With these extensions life is more practical but i'm still missing a key concept.

I stuck with KM Fastrans and had a discussion with the developer ( Angel ) on the concept of
fallback languages.

So say you have a site supporting EN, NL, DE. And an "item" is not available in DE,
it would fall back to the NL version and finally the EN version. So one does not need
to have all pages in alle langues. Or have only key pages in all languages.

The concept of "all" does not help in this. Is there a rationale in not having a fallback mechanism
for translated items from development point of view, is there some thread i can read up on?

I could not find it and some group members seem to walking ecyclopdia when it comes to these things

Cheers Marco
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/mr3ts9jltlYJ.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Nick Savov]

Hi Marco,

I notified JM, who is one of our multilingual experts, about this thread.
He's currently on vacation, but will hopefully be able to answer when he's
back (if someone else doesn't before then).

Cheers,
Nick

> I've had the "pleasure" of doing several multilingual sites which i ended
> up supporting
> with a 3rd party extension to make things "practical". There are a few,
> like Josetta and KMFastrans.
> With these extensions life is more practical but i'm still missing a key
> concept.
>
> I stuck with KM Fastrans and had a discussion with the developer ( Angel )
> on the concept of
> fallback languages.
>
> So say you have a site supporting EN, NL, DE. And an "item" is not
> available in DE,
> it would fall back to the NL version and finally the EN version. So one
> does not need
> to have all pages in alle langues. Or have only key pages in all
> languages.
>

> The concept of "all" does not help in this. Is there a *rationale* in not
> having a fallback mechanism
> for translated items from *development* point of view, is there some

[Marco Dings]

I am aware of the specialists I am not aware of their vvacation schedule. :). Thanks for relaying the message to JM.

[infograf768]

Hello
It was never the intention originally to create a replacement for Joomfish when we implemented multilang in 1.6+
Thus why a fallback mechanism does not exist. The purpose was to make it possible to create simple multilanguage sites where each Content Language would display whatever looked necessary to the site admin (Ex: 10 menus and 200 items in English, 2 menus and 12 items in another language, etc.), thus why the switcher would by default redirect to the Home Page for each content language.

Until 3.0.2, the only associations possible were anyway for menu items (added in 1.7) as it would have required major changes for each core components to implement items associations.
In the days to come, and hopefully completed for 3.1, items associations will be implemented for all core components and a wiki doc published to explain to 3pd how to modify their components to take advantage of the feature.

So, to make it short, the easiest way at this stage to create fallbacks is to batch copy the item concerned to the Content Language where there is no localised translation and then associate it. If/when a translation becomes available, it's simple to replace the said content.
The Tag "All" is not used for this purpose as it allows displaying the same items for each content language without using the lang switcher, providing one has created the necessary menu items.

One way to build a multilang site which would act as Joomfish in 1.5 is to systematically batch/copy all the default site language structure and items to their equivalent for the other content Languages and then modify these to fit when translations are available. Then do the same when a new item is created.

If a patch is proposed that would let do that in an easier way (batch copy for example at the same time all the categories and their items) via the batch functions, we would welcome this in core.

Another nice improvement would be to implement at all times the display of the lang switcher and the various flags only when associations do exist (and on Home page) if desired.

Any other working proposal is welcome.

JM

[Marco Dings]

Hello JM,

On Tuesday, 11 December 2012 09:21:43 UTC+1, infograf768 wrote:

Hello
It was never the intention originally to create a replacement for Joomfish when we implemented multilang in 1.6+
Thus why a fallback mechanism does not exist. The purpose was to make it possible to create simple multilanguage sites where each Content Language would display whatever looked necessary to the site admin (Ex: 10 menus and 200 items in English, 2 menus and 12 items in another language, etc.), thus why the switcher would by default redirect to the Home Page for each content language.

Although i am aware that joomfish has such a feature, my desire grew out of practical usage.  It good to understand the rationale at the moment of conception of the idea. I have no intention or desire to critisise that process, i try to look ahead at ways to improve the experience. Not saying you gave that impression, just trying to be clear and positive.

 

In the days to come, and hopefully completed for 3.1, items associations will be implemented for all core components and a wiki doc published to explain to 3pd how to modify their components to take advantage of the feature.

Ok well understood and apreciated.. 3rd parties are using the same concepts in 2.5 extensions already.

 

So, to make it short, the easiest way at this stage to create fallbacks is to batch copy the item concerned to the Content Language where there is no localised translation and then associate it. If/when a translation becomes available, it's simple to replace the said content.

I've done that but i found it not practical. I found that 3rd party component i use already allows me to copy a menu to a new language. I found however that this also requires knowledge, discipline and a certain work flow.
One should ensure the translated categories are available as well as a translated article. Then there is the menu aliasses, , (html) modules, components and extensions that need to be supported. It's not trivial.

I used the above process to do integral translation from dutch to english for a patient organisation cmtc.nl. In that context we find that we have volunteers that are willing to translate key pages to hungarian, chinese, russion etc.. This would allow users to search in their native tongue and find us on the key issues regardng the disease. Translating the entire site is just to much.

The Tag "All" is not used for this purpose as it allows displaying the same items for each content language without using the lang switcher, providing one has created the necessary menu items.

Understood

One way to build a multilang site which would act as Joomfish in 1.5 is to systematically batch/copy all the default site language structure and items to their equivalent for the other content Languages and then modify these to fit when translations are available. Then do the same when a new item is created.

For any way forward it's probably good if the Josetta and KMFastrans ( and others building/extenting on the native multilingual support) would get involved. I've bought and used josetta, i now am using KMFastrans. It is not perfect (yet) but in its setup it revolves around "translation sets" and in that sense it fits the joomla way forward.

If a patch is proposed that would let do that in an easier way (batch copy for example at the same time all the categories and their items) via the batch functions, we would welcome this in core.

Thats a good thing to hear, my assumption reading this is that it is not limited to the idea of batch copy. So if there was a way to do fallback it would be considered.
I'm for sure no the one to propose these changes (at this point). But i am going to take it up at leastr with the extension developer.

Another nice improvement would be to implement at all times the display of the lang switcher and the various flags only when associations do exist (and on Home page) if desired.

t would indeed.

Any other working proposal is welcome.

Thanks,
Merci beaucoup pour la réponse et l'interruption de votre vacances ;) ( boy am i glad this is an English forum )

JM

Marco

 

[elin]

The default language issue is really hard because of how multilingual was implemented as a filtering system rather than as a translation management system. I think it will be central to what we do in whatever we call what comes after CMS3.  At that point with UCM in place we  will be able to track the original language of each piece of content and then the languages of translations for sites that do translations. That way either kind of implementation (filter versus translation management) will be possible as will allowing a user to pick multiple languages in order of preference (rather than one as now).  In the meantime you can pull a kind of default language from the parameters of com_language.

Elin

On Tuesday, December 11, 2012 5:07:10 AM UTC-5, Angel wrote:

Hello,

I believe that the proposal of Marco Dings of having a default language can be very useful. The problem on having the same element replicated n times is maintenance. If you have a site with 5 languages ​​for example and have a default language, when you modify an item in the default language you only have to do this once. If you have the item replicated five times you have to make the change five times.

Although I have not studied this in depth yet, I think what should be done is:

1. Define one content language (or two) to be the default language to display items that have no translation into the LS selected language.

2. Modify all places (component models, libraries, modules and some plugins) in which items in the selected language and the language 'All' are read from the database to read also the items in the default language.

3. Modify the LS to choose the item in the default language when there is no translation of that item to the selected language.

I have expressed this in a simplified form and I'm sure I've missed a lot of things.

Cheers,

Angel M.