What features would you like to see in future versions of Joomla?

Full multi language support

The possibility to translate everything (articles, menus, modules etc.) into different languages without the need of a 3rd party component.

1,318 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    35 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Pedro Manén VivesPedro Manén Vives commented  ·   ·  Flag as inappropriate

        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.

      • Oscar RuízOscar Ruíz commented  ·   ·  Flag as inappropriate

        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.

      • WebTrebolWebTrebol commented  ·   ·  Flag as inappropriate

        The 1.5 version of joomla spanish have a translation manager incorporated, I love this component, it could be part of 2.5

      • mortimermortimer commented  ·   ·  Flag as inappropriate

        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 DesignElektra Studio Design commented  ·   ·  Flag as inappropriate

        @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?

      • Elektra Studio DesignElektra Studio Design commented  ·   ·  Flag as inappropriate

        @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 KimGiu Tae Kim commented  ·   ·  Flag as inappropriate

        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 multiregionsmultilanguage multiregions commented  ·   ·  Flag as inappropriate

        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.F. S. commented  ·   ·  Flag as inappropriate

        @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.F. S. commented  ·   ·  Flag as inappropriate

        @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 DesignElektra Studio Design commented  ·   ·  Flag as inappropriate

        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.

      • tobbytobby commented  ·   ·  Flag as inappropriate

        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.

      • adriaanadriaan commented  ·   ·  Flag as inappropriate

        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.

      ← Previous 1

      Feedback and Knowledge Base