Full multi language support
The possibility to translate everything (articles, menus, modules etc.) into different languages without the need of a 3rd party component.
[Deleted]
shared this idea
35 comments
-
Pedro Manén Vives
commented
Seria ideal poder enlazar todas las traducciones, similar a los items de menú, que en la versión 2.5 se pueden vincular, Sería genial poder vincular todos los contenidos, como contactos, artículos, categorias, etc. De forma que si una artículo no esta traducido te salga el artículo con el idioma por defecto.
-
Anonymous
commented
This is already the case since version 2.5, luckily.
-
Oscar Ruíz
commented
Acabo de postear algo similar en español.
Excelente, sería genial poder uno realizar un sitio multiidioma sin necesidad de terceros, simplemente instalando el core de joomla, el pack de idiomas a usar y listo.
Felicidades a todo el Equipo, excelente iniciativa y por favor tengan muy en cuenta esto para la versión 3.0
Muchas Gracias de verdad.
-
kalodez
commented
We elaborated a web service to hire professional individual translators within the WCM and to get the translation back into the WCM for Drupal.
We would love to customize it for Joomla, but need a helping hand.
An article with more details (in German):
http://www.contentmanager.de/magazin/news_h47094_nativy_connect_professionelle_uebersetzer.html -
WebTrebol commented
The 1.5 version of joomla spanish have a translation manager incorporated, I love this component, it could be part of 2.5
-
Antonio
commented
Yes, please! I really need it, it's so absolutely necessary nowadays...
-
Spiros Doikas commented
An absolute must for a modern project.
-
Fabio Perri commented
Very very great idea !
-
Erick B
commented
Full multi language support with different domain name per language
-
mortimer
commented
Yes, the multilingual system from Joomla is very bad, for any projects i use another CMS as Drupal.
Multilingual system is very important for many projets, the Joomla system not is usable.....
-
Elektra Studio Design
commented
@Polpaulin: We have, in life, the ability to choose our best options. If Joomla will not be able to fulfill your needs, then go with Drupal. Simples question, simple answer.
Joomla take the "simple" approach, and it is one of its strongest features. Market competition is good. Lets aknowledge each system strenghts and use it.
And let's not forget, this idea pool is about Joomla, all right?
-
polpaulin
commented
Actually I need multisite for multilanguage , Joomla cannot do it
Drupal can -
Elektra Studio Design
commented
@F.S. & Giu Tae Kim:
F.S.: My idea isn't to "insert formatting to separate languages", albeit I think I know what you understood by it, but to insert specific database separator markers (think some weird mysql code here, with lang prefix, and info, something about 20 to 100 characters, and that cannot, in any way, be inserted in the admin area by mistake or purpose), and on the admin article edit screen, these database markers will change the display of the article/menu/modules edit screen to either a tabbed interface (one tab for each language, with all common fields) or a multiple-editor interface (one field for each language, grouped by language. Ex.: first all title fields, one for each language, then all alias fields, one for each language, then... you get it).
I agree that each article content in the database will be bigger than optimal, but I always tought that fewer (but somewhat larger) requests are more desirable than many smal requests to database. Keep in mind I'm not a programmer, and I maybe talking B.S. in this regard.
In the language config we can decide the priority and fallback languages (when content doesn't exist in some language, fall back to display content in another language). This will solve @Giu Tae Kim problem of alias, because you will have the ability to setup different aliases for each language, but you can choose to leave the other language aliases fields empty, in this case all menu aliases will fallback to main language.
This can't be so hard to implement: It will behave like a huge plugin acting before display (admin and frontend), filtering information. When an article, menu, whatever, is requested, it filters, displaying and indexing only what is inside the specific language database marker that was requested. All the rest is bypassed (and if possible, not even read, to save processor cycles, bandwidth, time, etc).
It can even be shipped disabled, for single language websites (for faster processing), then activated when you activate multi-language. When activated, it will scan all articles/menus/modules for the language markers, and add to those that doesn't have it. Existing language markers will be preserved (if some, or all, languages were deactivated, and in the future reactivated, the work isn't lost). When adding a new language, after saving it will perform this scan, adding the new language markers to all items in the site. In the language config, you have the ability to delete a language (which will keep all content for this language, hidden in the system, with the correct marker), or even perform a scan to delete all content for this language, but this should be done after two warnings and a password input.
For publishing each language, we can simply change the "published" column to display the flag inside a green circle for published, and the flag in grey tones inside a red circle for unpublished (and a yellow circle for pending, blue for under revision, whatever). If the language for this article/menu/module is published and there is no content in it (ex.: an article without a translation in some language) it will fallback. If the language is not published for this item, this item will not exist in this language. This solves the problem of having different content for each language.
We doesn't even need to mess with the core. This can be developed in parallel, as a plugin.
If my suggestions are good, I'm willing to submit a spec sheet, screens, etc, to speed up the process. We all need a multi-language that our clients are able to use (joomfish is too complicated for a client that have no deep web knowledge).
Well, that sums it up. I hope this move forward with or without my suggestions.
Best regards for everyone.
Jonathan Roza
-
Giu Tae Kim
commented
Also the possibility to create one-level menu items with the same alias, but in different languages.
That cause I use languages that are similars (spanish-portuguese - I.E: Inicio / Início) or in case of non-latin characters like korean (Frontpage should be home, but this is used by the english language). This kind of things make the url stranger than it already is
-
multilanguage multiregions
commented
But it also needs the possibility to unpublish anything on specific language if content manager like so !
Some informations are sometimes just for specific regions / languages.And this is the next one : seperation of language and region
Thnaks to all
-
F. S.
commented
@Infograf & ElektraStudio Design:
Does there exist a bugtracker&ideapool especially for the language-support sub-project? I can follow all of Elektra Studio Design's ideas but maybe it will not be possible to follow all at once but on the other side you have to keep the target in sight! So, currently linking menu-entries works fine. next step would be linking categories and content items, so one can surf down to a single content item and then change languages.
Of course we have to think about how to create multiple language content as easy as possible. I might not want to insert a couple of formatting in an article for each language. Maybe there is a way to separate articels again into two parts: Format and Content. e.g. you create an article template for each article and afterwards you edit its content by language. but this might change the core content behavior and we will have to keep in mind that most Joomla users still only use one language. -
F. S.
commented
@Infograf & ElektraStudio Design:
Does there exist a bugtracker&ideapool especially for the language-support sub-project? I can follow all of Elektra Studio Design's ideas but maybe it will not be possible to follow all at once but on the other side you have to keep the target in sight! So, currently linking menu-entries works fine. next step would be linking categories and content items, so one can surf down to a single content item and then change languages.
Of course we have to think about how to create multiple language content as easy as possible. I might not want to insert a couple of formatting in an article for each language. Maybe there is a way to separate articels again into two parts: Format and Content. e.g. you create an article template for each article and afterwards you edit its content by language. but this might change the core content behavior and we will have to keep in mind that most Joomla users still only use one language. -
Elektra Studio Design
commented
We should rework the language system at the core level, but without much hassle. Here is the idea:
- Each article, menu, module, etc, have, in itself, all fields for all languages. I mean, if I have a site with 4 languages, when I edit or create an article, I will be presented with 4 fields for title, 4 fields for content, and so on.
- Alternatively, we can adopt the "tabbed" model from K2 and present each language in a tab, with all the fields (title, content, meta, keywords, etc) inside.
- At the database level, we can still use the same cell for each field of each article, using a encoded internal separator (a specific string, much like the hr readmore tag) to separate each language.
- A configurator to allow default language to be shown if there is no translation in a specific language is a must.
- For modules, we can add a "no show" option for disabling showing a specific module under a specific language.
- If we use tabs to separate the languages, we can (on ACL) allow editors to edit only a specific language without much effort.
- For extensions, I think the developers won't have a difficult time adapting, as the system doesn't do extensive modifications to the core.
- For a "legacy mode" extension support, we can allow a separator string inside the field (title, content, etc) to separate languages in a old extension. Something like "title|string.separator|título|string.separator|Titel|string.separator|Titre" with a specific string, or even a button to insert the string beside the field.In this way we can allow a user-friendly interface in backend (very much needed), and keep core modifications to a minimum, and even allowing for "legacy support".
I hope to have contributed, and I'm avaliable to do a very detailed spec sheet, and even coordinate the project in shaping its structure.
-
tobby
commented
I think the most important next step for the core would be to introduce a "link" table to link table items including language code. A common link table for all extensions would be to preffer before adding tables for every single extension.. Compare with the assets table. I see one of the deficits of JoomFish, beside the translation handling, is the translation table size. (number of entries).
I so far wrote 2 J! 1.6 componets and 1 module using the multilingual functionality. So far lucky enough not needing an extra table to link the items.
Well another thing would be nice: That you need a (*) All language home is ok as you can hide it in a not visible module position. BUT the breadcrumbs look very funny with two home levels. The language dependent would be enough. -
adriaan
commented
I personally think that the multi language in J1.6 is a very good first step. One advantage should be that the language switcher will not open the default page of a language but that articles with same content in different languages will have a link. Using the switcher at Article 2 in language A will open Article 2 in language B. If there is no link to Article 2 it will open the default page in language B. That functionality is already present in Joomfish.
