What does "Multi-lingual" mean to you when discussing Joomla CMS?

[jmcbade]

There is a Google Document being reviewed and commented on that Elin has sponsored.  So, good discussion going on there, but I wanted to take the liberty to bring this discussion to the forefront of the CMS community's consideration.

So I ask the question - would like to know how the rest of the Joomla CMS community defines "Multi-lingual Website" and how would you see it functioning for your use case?

There are two main ways of looking at this - two implementation scenarios:

The way we use it on our sites:
All content; Menus, Modules, Categories, Articles, everything, are posted in at least two languages.

Every item in one language, has also been (manually) translated into the second language.

ex:  Joomla is configured as a ML site as described in the documentation.
There is a menu item pointing to article A and when the visitor is looking the site in language 1, they see article A in language 1.  If they switch to language 2, then the see article A in its' translation into language 2.  All content has parallel version of the same content in respective languages

Another way being discussed:
"Multi-lingual" is defined as supporting to "forks" of a site under one URL.  If the site visitor is in language 1, they see a set of content; Menus, Modules, Categories, Articles, everything in language 1.

If they switch to language 2, they see a different set of content; Menus, Modules, Categories, Articles, everything, not necessarily translation of language 1, not necessarily parallel to the content in language 1.


The bottom line on language (for us):
This is really important to us in the organization I work with, as well as other organization I work with here, that have committed to Joomla because  (at the time using JoomFish and now with ML being a "core consideration). We are also concerned as to how easily the content would be managed - specially if we need content in respective languages to be in "parallel" so to speak. 

Management is key:
What is translated and associated, what is not.  What needs to be - i.e.: pending  When we change the status of an item, does the status of the associated item also change?  If we archive or delete one, does the other follow?

I think it's import to define the definitions, the use cases and thus, the goals of  "Multi-site under one domain according to language" differentiated from "Multi-lingual site with parallel translated content".

Thanks!

-John

[crocoast]

I personally would love to see the "fork" part being the thing that joomla would go towards.

I would expand on it by saying that perfect for user would be if the menu that has been set up in language1 didn't have to be copied or re-created but would detect the article based on article option set in article itself, so when edditing article you would choose language as we already do, and based on your selection it would show the appropriate link.

I don't know if you can understand which way i am going, i can put this in more detail if you like but that is basic idea that would appeal to my customers very much, since they would not worry about menu structure that much and would just edit article and choose language there.

at present there is too much work doing the ML site since for every language you need seperate menu created, now imagine how many times you have to do that if you have 10 languages and 1000 articles, sections and what not.

Just my point of view guys, trying to put stuff on table.

Josip

[jmcbade]

Josip,

Really appreciate the time to answer, pretty sure I DON'T know what you mean exactly :)

Are you saying no "parallel" content, but basically two different websites under one URL?

Quote: "I would expand on it by saying that perfect for user would be if the menu that has been set up in language1 didn't have to be copied or re-created but would detect the article based on article option set in article itself, so when editing article you would choose language as we already do, and based on your selection it would show the appropriate link."

You have lost me.  How would this work?

But then it seems like you want to somehow have related - say an article - that some how shows up according to language - but aren't associated?

Quote: "I don't know if you can understand which way i am going, i can put this in more detail if you like but that is basic idea that would appeal to my customers very much, since they would not worry about menu structure that much and would just edit article and choose language there."

And how would it be associated / linked to a Menu/Menu Item in the language for the visitor?

How would a non techie editor/publisher, know what was translated and what was not in comparison to each language?  Seems, if I understand you correctly, either Joomla is magically figuering this all out, or, the expectation is the editor/user is also intimately trained how Joomla works and how it is set up for a particular site.

With the menu items for example, how would the menus, menu items be translated then?  I am not getting how you would get around having to have the menus and items translated?  I would presume you aren't having Google or something do it?

Thanks :)

Looking for a real world example :)

-John

[crocoast]

No problem let me go into detail of what for end user would be the best, please bare in mind that i know the technical limitations and work that needs to be done to achieve this.

Case as it stands right now:

We have created article1 article2 article3 under one category1

we want to add menus for linking articles to menu1

we go to menu add menulink1 -> article1, menulink2 -> article2, menulink3 -> article3

Now, if we want to translate that we have to create a brand new menu and translate articles, for the sake of the case gonna call it language XXmenu1 (xx is translated article) so we would have :

menulink1 -> article1, menulink2 -> article2, menulink3 -> article3

and for XX language another menu

XXmenulink1 -> XXarticle1, XXmenulink2 -> XXarticle2, XXmenulink3 -> XXarticle3

and so on.

hopefully i am getting this right, please bare in mind english is my second language so i am doing the best i can :(

Now the idea from customers feedback would be to be able to make only ONE menu (menu1) with links to original article (article1, article2, article3)

that is where creation of menues would stop, the idea is that XXarticle1, XXarticle2, XXarticle3 are linked to same menu (menu1) and that the translated text is shown thus reducing the creation of multiple menus. We already do have flag for language of the article.

so the structure would look something like this:

menulink1 -> XXarticle1, menulink2 -> XXarticle2, menulink3 -> XXarticle3

As far as the menu title and menu alias it would just pick up translated title and alias

the whole idea is to reduce steps for enduser to create ML site, it just is pain for normal users to add menus for each language and they usually mess them up and i have to go in and fix links, but it is EASY for them to do translation inline with the article, and choosing the language flag there in edit article view. that is where they would like to stop with thinking.

I hope this makes sense, i have it in my head but i might not be good at explaining and putting it in english.

[John McBade]

So menu item would only ever be in one language?  

Or how would menu item link show up in the other language?

Seems like it still has to be translated somewhere yes?

I think that is the part I am missing :)

-John

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/OxFOrR8A5vQ/unsubscribe?hl=en-GB.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[crocoast]

Innitially it would be one language which in turn would be used as default language. But for translation, the menu title and alias of the translated article would overwrite the default value for the menu title and alias.

Makes sense?

This is the idea only John, this is what customers asked, and i denied them since i dont know really in detail how translation works atm, so i am just putting ideas on table :)  i hope you dont mind.

Josip

[Captain Paralytic]

Here is my view. 

I have just set up a site with 6 languages but only consisting of menu item translations (the site is effectively a single page which supplies links to several country based multi-lingual sites. Creating all the menus and copying and then translating the items was quite time consuming and I'm sure a "normal" user wouldn't have figured out all that had to happen to get the languages al displayed.

I have to say that the Joomfish method was far easier to work with. Not perfect but certainly easier.

As crocoast has suggested and as Joomfish worked, I favour the creation of a single menu in the site's default (and fallback) language. A page similar to the one that Joomfish supplied could be used to see what items still required translating for a particular language. Menu items would be translated there and the translations published. If a particular item did not yet have a translation, then the item would be displayed on the frontend using the default language.

When an item (by this I mean any object, so article, menu item, ...) is edited in any language, there is a warning that the other language versions, may be out of date. This includes a warning for the default language. Again a function supplied by Joomfish.

When a default language item of any sort is un-published, then I feel that should happen across all languages. If a translation of any item is un-published, then the default language version should once again be displayed.

Hope that makes sense.

[crocoast]

yes this is what i was getting to next, wanted to clear the setup first.  in my head i do have whole structure and i am just sorry that i am pretty bad at english to describe it, just wanted to help :(

Josip

[crocoast]

Reason why i think it is possible is that menu is linked to articles via article ID, and this is pulled from database, what we could have is a check to see if translation is added to the article and if so then take ID of translated article and put it in place of default article ID, but only if it was called by the user by asking for translated text (link by flag or however).

This would be very very efficient way of doing things, since it would streamline the process of site creation and most of all maintenance, and plus it would give us a benifit of having content for everything even if there is not translation on certain articles.

This is my view of course guys please dont take it the wrong way.

Josip

On Tuesday, 11 June 2013 13:02:22 UTC+2, jmcbade wrote:

[brian teeman]

That would ONLY work for menu links to single articles

[crocoast]

This was example, of course need more detailed look into it, but in general it is possible? since for categories it would be similar too.

Just putting things on the table :)

On Tuesday, 11 June 2013 13:02:22 UTC+2, jmcbade wrote:

[brian teeman]

It needs a lot more detailed look. I believe you are going down a false path

[crocoast]

Ok, noted, thanks for the heads up.  you have to admit it would make it very easy for the end user without any tech knowledge.

[Bakual]

Just asking out of curiosity: How could one find that document? Did I miss the link?

[JM Simonet]

These are my definitions:

----------------

1. A monolanguage site is a site where the UI is in the possible language packs installed on the site (depending on decision from site admin and registered users), whatever the contents.

2. A monolanguage site may have some contents in different languages. These are displayed via menus and categories. There is no switch/associations from one to the other except by using the menus.

3. A multilanguage site is a site where one can switch to a version of the site in a specific language to another, switching also the language of the UI at the same time. The contents are tagged to the Content Language chosen or ALL, but the UI always changes to the chosen language.

Some associated contents/items may not be in the UI language depending on the site admin. Example: a mulitlanguage site in English and French may have articles in Tibetan tagged to ALL or to a specific content language.

The associated items do not necessarily need to be translation. Not all items need to be associated. This is the big improvement imho compared to the fish and similar systems.

4. A multilanguage site may or not be displayed as multisite, using different domains if set so (A feature we badly need in core. An extension is available on JED)

What are the possible improvements in the short term that I see to what we have now?

A central component letting manage the Associations globally in its own interface, with content comparison when the association is a translation.

Defining fallbacks when an item is not associated.

Hope it helps

JM

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

-- 

Merci de ne pas renvoyer de pièces attachées automatiquement.

------------------

Jean-Marie Simonet/infograf

info...@orange.fr

http://www.info-graf.fr

[wdburgdorf]

I totally agree with infograf's definitions. And I'm glad this discussion is coming up. In a country with 4 official languages plus English (Switzerland), multi-language capabilities are essential. 

For all the multi-language sites I have done with Joomla I used Falang. I find this a nearly perfect solution, my clients like it, too. It's simple, straight forward, no double content, nothing's forgotten. The problem with it is, that the quality of Falang is not great. Basically works, but we often have small issues with it. Apparently it's just too much work for a single person to develop, maintain and support.

Then, it's not THE standard, many extensions are not supported. So we have to carefully choose extension depending on whether they support Falang (and sh404sef, and K2 etc.) in the selected version of Joomla -- quite a limitation.

We never needed a multi-site/multi-domain for any client, so that's not a priority for us. Simplicity and speed is, and avoiding the possibility of errors (such as associating the wrong pages/articles, forgetting translations and updates). That works well with Falang.

(Actually, I do have one client with a multi-site solution, but I used Contao for that. There, sites have independent page trees, and pages in different languages can be associated to pages in the default language tree. There is an extension for Contao to manage languages, i.e. to show the state of associations and translations. Like that it works very well for multi-language. I only mention this because I find it useful to check how problems are solved elsewhere.)

The current standard built in multi-language solution does not work at all for me. For 10 pages in two languages, it may be ok. But for anything more than that?

Another consideration for me is how translations are done. With Falang, all translations are managed in one place. Like that it is possible to give access to Falang to any translator who has no idea about Joomla and has no access to anything else, and he can still do his job easily after a 10-minutes introduction.

On Tuesday, 11 June 2013 13:02:22 UTC+2, jmcbade wrote:

[George Wilson]

There was a nice talk about multilingual stuff at JAB '13. This focussed specifically on one component (can't remember which off the top of my head) which allowed the linking of menus, articles, categories etc. much more easily than is done at the moment! Also allows easy creation and notifications of missing languages. Its the kind of thing we'd really need for large multilingual sites in my opinion.

When it gets uploaded onto youtube it's definitely worth watching

http://jandbeyond.org/program/sessions/practical-multilanguage-websites.html

Kind Regards,

George

[jmcbade]

Yes.  I have been in contact with Angel for a few months now.  His extension is thus far, "best of breed" beyond what the core does now.  I am anxious to see how his extension functions with the bit of enhanced functionality added to core in Joomla 3.x

Our staff did the Japanese language translations of the strings for this extension.

Thanks Angel!

[jmcbade]

[jmcbade]

On Tuesday, June 11, 2013 8:02:22 PM UTC+9, jmcbade wrote:

[jmcbade]

This is the part of the response from infograf I find the most agreement with:

Quote:

"A central component letting manage the Associations globally in its own interface, with content comparison when the association is a translation.

Defining fallbacks when an item is not associated."

If I am reading this correctly, this most fits with what I am trying to describe in my first section.  It is maybe the closest to describing the most basic part of what other extensions have attempted to perform, but had limitations that made them less than optimal.

I hope I am misunderstanding the perception in this other description, (this may be a language issue - how ironic!), that we "need" the ability to have multiple sites of un-synchronized content by language under one URL. It any development effort was further added into Joomla to do this, and not to solidify and enhance the abilities of translated content according to language of "parallel translated content", I would find that most frustrating to say the least. 

This is why I want to encourage really in depth discussion on this topic.  I feel in my 7 years of using Joomla, that so far this worthy functionality of Multi-lingual parallel translated content, has been again, left to less than optimal "after thought" solutions.  Having used products like Joomfish, although very thankful that there was some solution available, I have discovered many really badly impacting issues with them.

In my discussions in forums before Joomla 3 was in Alpha, the response I got was that due to "developmental / historical design decisions and that these made effecting a better core solution very difficult, we would have to wait for 3.x and beyond.  Now it is again, critical for my user base that easily managed functionality of Multi-lingual parallel translated content remains a clear part of the design goal. 

I think what needs to be a very key part of this kind of development, is the provision of simple and clear content/translation management, that would be easy enough for a "non-Joomla admin" to perform.  Most translators in the organizations I work with are volunteers who are not web professional.  Their skill set focuses on translation.

I would think, because of the symmetrical nature of parallel translated content, creating easy to use and understand management tools would seem, at least at face value, much easier than maintaining divergent alternate content ie: one site in one language and another using a different language accessed using the same parent domain.  The latter seems it would require a extensive, intimate and high effort for maintenance, being the lack of synergistic relation of content.




    

[elin]

Wow I go away on vacation and miss a lot.  John's talking about a  document with a list of language related questions for JM plus some brain dumping by me that I shared with him when helping to debug some problems on his site.  It's not really a polished thing, but if and when I think there's something in readable and well organized paragraphs that actually makes sense I'll post it up.

Good discussion, I think one of the interesting questions is the first one. There are a lot of different meanings to multilingual/multilanguage (we see some right here) and whatever we do needs to support all of them as well as it can and also needs to encourage extension developers to participate through the use of easy to use APIs. We've been really successfull with the JText Api and with supporting all languages.     It's hard to remember that before 1.5 we did not support all languages and that before 1.6 among other things you could not translate text in javascript.  Now we have finally added support for idn URLs and email addresses.  With 1.6 also we took a lot of steps forward by among other things adding language as a common field across all content types so that it is now possible to run queries that filter on specific languages and of course that then allowed us to build the multilingual system we have now.   It's hard to believe that we have not had that all along.

In thinking about the CMS and its apis it is important to not assume that what you want is what everyone wants and that's why I think the opening question is an extremely important one and one people have been talking  about at Joomla events, in development discussions and elsewhere for many years.  So building out a solution may involve several separate solutions.  For example, some sites may want to manage fully parallel sites with 1:1 correspondence of "pages." (In truth PHP and SQL care not whether those pages really are translations or are totally unrelated)  Other sites may simply want to include content in a number of languages but in a less holistic way, but they may want to simply allow people to use search to find content in a specific language, something else we support now that we didn't in the past.  
Some people want to have a clear original version of content (important for translation management) while others don't want to give primacy to one copy.

There are also many important questions that relate to other parts of the CMS platform. For example, if you have a parallel content structure should your urls (whether 2.5 style urls or the japplicationweb style urls or something else) should be translated and what does that mean in terms of look up.  Just thinking about the mechanics of how you store translated menu aliases is pretty interesting.   While it is good to think about what kind of user facing functionality should be possible either in the core or in extensions, building any of that requires some serious decisions on what the apis for that look like.

A lot of this obviously has to do with the content model. If you have associated articles in 6 languages are those fundamentally 6 separate pieces of content that you have mapped together or are they one piece of content that has 6 variations.  Which model you chose has very important ramifications.

Finally, I think it's really important to totally separate the issue of what kind of translation management tools the core CMS should or should not provide from the question of what is the multilingual experience for site visitors using different languages like and also from the issue of setting up navigation and so on. 




Elin

[ma...@sooyco.com]

I think the way that you do it is the best way to do it.  If you had to fork out a different CMS for each language, it may be more difficult to not only keep track of content posted, but also upgrades and such.  Which brings to mind the question; Who is the ultimate end user of such product?    Are you going to have multiple admins versed in different languages and thus they need to keep track of their own respective sites?