By gábor hojtsy on

Fortunately following our call, many of you took the time to write up your ideas and frustrations about trying to set up multilingual sites with Drupal and other content management systems. The matter of fact is that many of the Drupal developers already went and done some content translation solution in the past (sometimes coupled with menu, categories and other translation possibilities). While we are brainstorming about what should be supported, we should also think about the connection between the frontend and the underlying technology.

For this reason, I have took the time to review four existing solutions for your Drupal content translation needs. All of them have their own weak points, and most of them have very good ideas to carry on into Drupal core. Specific implementation and interface details will be discussed at the internationalization group site. By publishing this report, I am trying to visualize what are the common approaches taken and what alternative paths are tried to support different needs. Hopefully we will be able to select a proper set of these which allow for versatile user interfaces to be built around content and navigation translation.

In case you find any errors or omissions in the comparision table, feel free to point them out.

Comments

jax’s picture

jax commented

There is a patch available to fix "Menu items point to" for i18n module suite:
http://drupal.org/node/76631

With this patch, when you switch languages, the menu item points to the translated node.

mehovina’s picture

mehovina commented

Was looking for this patch for the last two hours, I knew I saw it somewhere it the past and here it is. Just to say appreciate the link

jose reyero’s picture

jose reyero commented

Hi Gabor,

I think you've made here a very good analysis, and quite accurate, at least about i18n module features, which is the one I know best. The only important mistake I can see is the spelling of my name :-)

Just to note that i18n does switch taxonomy terms -with the 'translation' block, not with 'languages' block.

Also, an update -for i18n 4.7- has just been released fixing some bugs and with some new features:
- New module for profile translation (i18nprofile)
- Translation workflow, allowing some 'translation' status + some content administration page for translations.

However, besides all these nice features all the modules have, I think we also should focus on 'how it is done'. I mean which specific solutions to specific problems are worth being reimplemented as some core patches, and which ones are just 'temporary solutions' to the problem.
I.e. while i18nmenu.module somehow addresses the problem it is not really something I'd like to present as a real solution for menu translations -that's why I placed that one in a 'contrib' subfolder inside the i18n package...

I'm sure that picking up some ideas from all these modules -I really didn't know there were that many- we'll be able to build some great solution for Drupal and multilingual sites.

Keep up the good work!

https://reyero.net

mbria’s picture

mbria commented

Thanks a lot Jose for your wonderful module and specially for this last improvement.

I always play with profiles in my sites, but until now I never find a nice way to translate them... coding t() in the themes and so on.

I just hope one day your module will be included by default in Drupal.
No offence for other great developments, but Gábor... Jose's internationalization module is a killer module.

Really simple and clear for the final users and as far as I see, your code is well thought and structured.

+1 for him and this module as the basis of any future development.

Un abrazo y gracias de nuevo por tu magnífico trabajo,

m.

wonderland’s picture

wonderland commented

I have to agree, a big THANK YOU to Jose. You've developed a great set of modules. I just hope there will be an upgrade path to whatever i18n solution Drupal core will get.

..- Wonderland

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

I would like to tackle some questions to define the proper approach of 'how it is done'. We need to think about the database+code side of things and the user interface. Things are better discussed one-by-one, since we will get a better picture of the general feeling of people about them IMHO.

I am trying to extract some good approaches from the modules I examined to see how we can match the use cases sent in by users with those, and what needs to be built into Drupal. The first question already up is how should nodes and their translations get handled (since it is often a cited disadvantage of the current approach that we have content duplication). See that discussion.

You are doing very good work in this area. Keep up the experiments, as all the positive comments show, people love your contributions!

jorditr’s picture

jorditr commented

Hi Jose and Gabor and all of you. First of all, thanks to Gabor for such interesting study, and new thanks for José for this great module.

I think that maybe new things could be defined on that area, but José's i18n.module works, it's already working on many sites. It has to be said that last version for 4.7 is just great compared to previous releases just for the fact that it's so tightly integrated on Drupal 4.7 that it doesn't requiere any patch!! 8-)

From my experience (3 sites already with 3 or more languages) and seing the different debates here about that issue and its future core implementation I would like to point to a couple of points:

  • Duplication of nodes: yes, it duplicates nodes, I think that the only bad thing about it (since the only solution is that every node register handles all the translation which probably is a worst solution) is how those nodes are recognized and scrutinized by the system, and from my (hard sometimes) experience the only system which seriously collapses with it is Search which in my opinion could be extended to handle on its own configuration if searching on default or all languages independently of the i18n.modules configuration
  • Translation of taxonomies and menus (and other future things): probably the l10n solution (own Drupal's localization.module) is the proper way, and the easiest way is that every time we create taxonomies, vocabularies or menus we already had there all the boxes for introduce at once all languages, interfacing the localization module inside the other modules (taxonomy and menu) and making that way life easier without handling with so many screens on so many parts or Drupal

On my opinion with these two elements solved i18n.module could go core, and if it was something that could be improved it would be on the next Drupal releases, as it has happened with the rest of core modules from its very begginning :-)

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

You are right, we are not tackling all issues at once, but we are trying to introduce an open system, on which countributed modules can build on (and we should keep in mind support for contributed modules already present, like workflow and actions or views, so that we are able to fit into their features).

Search is an interesting beast, when it comes to i18n, now it is not really possible to have separate indexes by language unfortunately.

jorditr’s picture

jorditr commented

Hi Gabor and all.

I don't know when should issues be tackled but I see several points from a strict practical point of view:

  • i18n.module could be better, but at least now it's great and it's independent and doesn't require patches, so, it's solid
  • "where should go the language "tag" to identify searches, menus, vocabularies, views, polls, forums?" is the "real question" not how i18n.module works itself; probably if those things were solved it would be reeeeeally easy for José to adapt it to the "core lines", as he has looked quite proficient until now with
  • how to properly handle firstpage could be another nice issue to solve
  • if taxonomies, vocabularies, menus and so on would interfere the l10n.module we have solved 80% of the problems I've found on my daily multilanguage work, the work with nodes is quite solved (from a functionality point of view), the problem is handling menus and taxonomies; what if, and I just say "what if", every time we enter a new menu, a new taxonomy, a new vocabulary on a multisite environment (something that could be on admin settings page: multilingual on, multilingual off, and handled on the variables tables as maaaany other system settings), so, what if when entering the menu name, instead of the single name field that assumes that there won't be no translations, then we had one for field for every activated language?? Is this conceptually so difficult? Which other solutions they expect to find? The logical way is that every time I create a new menu I assign the different names on every language, below the menu.module sets the basic name on the menu tables, the rest of the fields are sent to the localization tables on a transparent way to the user. Is so easy to solve! :-D Well, at least IMHO
  • I understand that core developers want to find a way to handle the translations to define a proper database solutions, but we have seen that on 4.7 they have changed the structure of the nodes realted tables, in fact they change those things whenever they want, I think that this would happen with that, they just need to compromise to start a solution :-)

Would it be the best solution on the whole world? I don't know, at least it would work, and it would work the way Drupal works today. And it would be as solid as Drupal multisites are... because they are already working today, but without any help for their developers and any glory for Drupal.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

Well, i18n is not solid in that Jose himself acknowledges that some approaches are rather experiments then real solutions. Well, in some cases we don't yet have better implementations for sure. This is why we are here!

"Firstpage" is solved by i18n module with language specific variable support.

Unfortunately using "l10n.module" (the t() function) is not so good a solution as it seems. Read: String translation: why using t() for user specified text is evil?

so, what if when entering the menu name, instead of the single name field that assumes that there won't be no translations, then we had one for field for every activated language?? Is this conceptually so difficult? Which other solutions they expect to find?

Tr.module does this field display, and it does it nicely (although it can be improved for sure, along the lines of my t() related post linked above). Another commonly requested feature is a one-stop-shop overview page for translators to translate strings, nodes, etc. You might not know your menu item translation in all langugages and you might not want to provide menu admin acces to those, who help you translate. So IMHO you need an integrated interface for simple cases when you know the translations. But if you leave some fields blank, you should be able to find untranslated menu items, etc on an overview page, which you can point your translators at. This is another solution we expect to "find".

I would not say that i18n.module itself works without the help of Drupal core developers. You are able to use i18n.module without patches, because those patches were committed (added in) by the core developers to Drupal in previous releases.

wonderland’s picture

wonderland commented

I have to agree with the original post, from a practical point of view all I want is a working solution that is considered stable and will be supported in the long term. I don't care if it is the best solution in the world. It should be good, but trying to make it too perfect is not always the best choice. Choose one approach, stick with it and make the best out of it. But I think that's what your're heading at anyway, with the great work on the comparison table etc.

But if you leave some fields blank, you should be able to find untranslated menu items, etc on an overview page, which you can point your translators at.

Yes, definitely. Not only for menu entries but also for untranslated nodes. And a seperate overview page for each language as often not every translator should have permission to publish in every language.

..- Wonderland

neruda001’s picture

neruda001 commented

Hi, I found your comments very useful and I tried to get the modules you posted here. But that I was looking for wasn't matching the add-ons module.
I develop using Drupal for a corporate web site, and I've made this CMS working as a online magazine.
I was looking for translating articles from italian to english, using an external translator resource, so the articles was already translated.
The work I've done was adding 3 colums to node_revisions table (body_en, teaser_en, title_en) and 6 colums to node_type table (has_teaser_en, teaser_en_label, has_body_en, body_en_label, has_title_en, title_en_label).
Now I've modified the node.module, so it displays me 3 new text area in the edit form, that would contain the translation of the article (body_en), of the title (title_en), and of the teaser (teaser_en).
Using a get variable in every URL, it can determine if show the italian page or the english page, without node replication needs. Just adding 2 times the body, 2 times the title, 2 times the teaser. And adding a litte php code that retrieve the GET variable from the URL and determine the field of the DB that would be shown in the browser (body, or body_en).
Have you any question/suggestion/alert?
regards & thank you.

Pablo.