The problem of the translation modules
I am wondering why the two translation modules I found for Drupal are not really translating anything. Instead they both use clever ways to moking new nodes and then sort of trying to hide they did that so for the users not minding urls it seems the page is now translated...
For this functionality I do not really need a translation module. I can make two nodes where one is the translated version of the other. And I am certainly able two make two menu's that show localized strings depending on which interface language is selected. That's all and I'm done with the translations, without modules attached....
The modules do do certain things which otherwise would be a bit harder to do but after 5 hours of trying I only have the Localizer module to work more or less ok. The Internationalization module still refuses to translate the menu and show it translated for each language as long as I refuse to use the build in string translator of the drupal core translation module (Home › Administer › Site configuration › Localization › manage strings). When I stop being stubborn and use the Drupal core's functionality then it works. The I18n module promises though that it translates menu's as well, but in reality I did it...
With that being said:
Time for some real translating?
For my own cms that I am trying to replace with Drupal. Amongst reasons for this change is not being the only developer any longer. I use a translation class that handles both the system text (using gettext) as well as any other user inputted text (using the database)
The way it works
The system is really easy although it will lead to one large table of translated text. All I have is a languages table defining the languages available (Drupal has that already; great!) and a trabslation table with the following fields:
- multilangType
- Type of object
- multilangTypeId
- Id of the object
- multilangFieldId
- Id of the field that needs translating. This may be anything that uniquely describes the field for the selected object
- multilangLanguage
- The language this record is in
- multilangText
- The actual translation
The way this works is that the system gets all of it's data but after collection it will call the translation module providing type, id, field id and optional language. The translation module then responds with the translated string.
Simple, right? And it is an actual translation rather then an attempt to confuse visitors with these changing url's (which for the i18n module weren't evn always correct)
Drawbacks?
I do realize that this means some extra data collection from the database, but through clever programming this can be minimized (one could with one query get all translations for "node/3" then sort it out using an array with field id's). There is really no problem with this approach for as far as I can see EXCEPT... It needs to be in the core for best use or else other modules can't/won't integrate the translation calls which makes stuff a bit easier. Otherwise a translator module needs to do all of this work on top of the existing single language modules. However, this is probably also possible, right?
What are your thoughts on this?
I am curious to see how other people see this, and if there is perhaps some mistake in what I am saying....
