A controversial(?) point: store translations as nodes

Someone pointed me to this discussion. I wrote the tr module
for a project I was working on in 2005...

In retrospect, I think storing translations as separate nodes is
not such a good idea. The problem of syncing translation nodes
is a serious one -- you have to do that for any module data associated
with the original node, e.g. dates, categories, flexinode fields,
etc. -- it makes things less manageable/extensible, and it works
against Drupal's node-centric design.

Instead, with the forms API and form submit callbacks, you could
add translation fields to edit forms, save the translations,
and then with nodeapi 'load', switch in translated text for just
those fields...

Of course, you also want to be able to filter lists of nodes by language,
but you don't actually need separate language nodes to do that, just a
record of which nodes are translated into which languages -- something
to filter against in db_rewrite_sql().

For translated menus and translated category names, the same approach
of form_alter() + switching text would work. It would require
patches to add hooks to switch the text, but just little ones. :-)
Per language url aliases would be trickier, but still probably easier
without multiple translation nodes.

...

After thinking about this, I got interested again and started working
on a translation module for 4.7 that takes the field-oriented approach.
It's basically working. UI needs fixes/comments, but I could put
it up somewhere for reference...

Rob

Goba mentions the following as an advantage for storing translations as nodes: Visitors to your different translations are counted separately, they can comment in the language of that node. To me, that would be a disadvantage. So, depending on what problem you want to solve, and your view point, advantages can become disadvantages -- and vice versa.

The issue comes down to this problem: translated versions of a node still have certain fields to share. Sometimes, you want to share these fields, sometimes you don't want to share them. For example, I want to aggregate the view counters, Goba wants to keep them separate. Same goes for the poll votes. Some people want to aggregate the votes, other people want to look at them separately.

Or how about comments? Do you want to mix comments in English and French, or do you want them in two separate threads? Certainly, the French comments are going to make things messy for English speaking people (those that don't know French). However, in Brussels where people are bi-lingual, mixing the comments might well be the preferred solution. Aggregating poll votes is one thing, mixing comment threads is another ...

Here is the current state of my mind:

• Conclusion #1: keeping certain fields separate or merging certain fields are both valid use cases. Ideally, we'd support both.
• Conclusion #2: merging or aggregating things on the fly is not a solution. It might work for counters, but it fails in other scenarios (eg. comments).
• Conclusion #3: from conclusion #1 and #2 follows that storing translations as nodes is not the preferred solution. It doesn't provide a framework to solve some of these problems (eg. comments).

I have installed and tried the translate module (that provides translation of only necessary fields) of Rob Ellis and at the same time I am working with my own module (localizer) that uses the opposite approach (nodes duplication) like Internationalization module of Jose.

I am afraid that the first approach (not duplicating) can introduce a lot of management work for contrib modules.
Consider for example a pretty content-rich module like webform : you have to recreate and manage the main interface
of fields definition for every language, that it is almost the same to have duplicate nodes.

If we use this approach every module maintainer must implement support for multilingual content, and in complex
modules this can bring to duplicate all the core content of the module in a separate table, that it is the same, from
this point of view, of duplicating the nodes.

I don't see any problem to duplicate the nodes. Having a node duplicated in the node table or having its most but not
all content stored in another table, for me is equivalent.
For my point of view translated contents are different contents, so it has a sense that every content has its own
comments and counter.
In every case, a system of sharing comments of counters can be easily implemented.
The only problem of duplicating I can see is the management. It isn't a real problem for simple nodes where
you have to change only the title and the description, but it can become a problem for example
in webform or poll modules.

I am not sure it is be possible, but perhaps a mixed approach could be a solution.
For example, for images, it has no sense duplicating the nodes : you have only to translate the title and
the description. And duplicating introduces also a problem of maintenance : if you want change the image,
you must repeat the change on every localized node, if we don't implement a synchronization system that
update the image reference on every localized node.

Roberto

In Norway there are three official (or is there four now?) languages. In certain municipalities you have to be able to respond to people in any three languages. All public information (laws, rules, etc) has to be provided in three languages. In all municipalities you have to be able to respond in at least two languages.

Two languages are understandable by all Norwegians in their written forms (New-Norwegian, no-nn and Book-Norwegian, no-nb)(some would say they don't understand, but that would mostly be a contrarian position; foreigners learning one Norwegian language can read the other), so comments to a node written in any of those languages could be interchangeable and interesting for both language 1 and language 2. These two languages are required for all municipalities in Norway.

Things written in the third language, Northern Sami, are not understandable at all for anyone who hasn't learned the language. This is a minority language from a completly different language family (Finnish-Urgic, as opposed to the Indo-European, Germanic which the other two are based on.) Only certain municipalities who have opted into this has to be able to respond in this language.

In one municipality (afaik) there is a fourth language, also Finno-Urgic, but completly different from Sami, which is also an official language.

A public servant answering a comment posted in no-nn has to answer it in no-nn; but the question and answer is certainly of interest for all no-nb readers as well. Furthermore it might need to be translated into Sami in certain municipalities, and if it is served on a state-level.

All this is required by law.

Of course, in practice this is very hard to do, especially for the fourth language which just a few thousand practicioners, Sami has tens of thousands, but I don't think all the departments have translators to translate every public document as they are written...

But, all taxonomy, all menus would ideally have a one-to-one relationship between the languages. Try out http://www.odin.no/odin/norsk/dok-bn.html as an example of a public site which is available in three languages, the link is to Book-Norwegian, in the second menu line there is a link to Nynorsk (New-Norwegian) and to Sámegiella (Sami). Note how the menus change their language when switching between no-nb and no-nn but the articles retain their original language (based on the language used of the author).

From a database normalization perspective I would go for the node version, contrary to what others might belive, the reason is that the extra information in the node is of interest for the current translation. The author info is unique for each translation (though an original might have several collaborators, like in a scientific paper, an investigative journalism piece, to mention two obvious candidates, and those would all need to be credited as authors in the author field, and should thusly be factored into an author table and have a one to many relationship with the node), the date of translation differs from the date of writing, etc.

Moving this into fields would create a layer which needs this kind of meta-information as well.

The information in an English node, a Sami node and a Norwegian node might be the same in a broad perspective, but don't forget that each language use its own idioms and ideas and thus translating a Sami node into English directly would show that even though the information is the same, the understanding would be lacking!

Of course, using nodes might be confusing for a first time user, but the current i18n with drupal 5.1 seems very good (from the very few looks I took into it), it even has acknowledged the fact that I don't need a copy of an image, just a translation of its description, so it seems it doesn't create unneccessary copies of a file, though I haven't had the opportunity to confirm this 100%. It also lets me upload a new picture in a different language if it is needed. Brilliant.

This path seems to be the right one for polls as well; the terms used in the poll might need translation, but not neccessarily a new poll. But the option to create a new poll might well be needed.

For example, a poll asking people about same-sex marriage might be apropriate in many countries, but in the Philippines even posting that poll would probably create an uproar. The same goes for many other social issues.

So that poll might have to be substituted for a different one in that country.

I like the workflow of the i18n, it fits into how I think. I like the possibility of assigning roles to people, you are a French translator, you are a German translator etc. It fits with the real world.

Disadvantages:

Aggregated poll results. If you are polling the answers based on spoken language, where you live etc. adds flavour to the analysis, and therefore are interesting. That's actually an advantage! As for the date and venue of an event. That is problematic, but just an UI issue.

Then to the advantages you mention.

Clean URLs, that's just an UI thing, therefore it can be solved for the field approach as well as for the node approach.

My advantages:

The author and the translator are different, the date of a translation is valuable information in its own right. I want to control when a translation is published, there are different versions of translations. Information is the keyword.

I can send a link to a node to a translator and she will have the same interface as if she wrote a new node, with her own translated interface, thus clearing up any ambiguity in an interface with several columns of information which needs to checked. Open two different browser windows to see the original and the translation, in their proper context, and in simpler UIs. Usability is the keyword.

The parts we're not discussing are those which have given me most problems in the past.

No further comments here for six months plus, well here's mine:

I'm 100% behind the idea that the language that a node is displayed in is a display function. I want it displayed in English or French is the same as I want in displayed in Pink, or using the Garland theme.

The underlying problem is that machine translation doesn't work. If machine translation were 100%, nobody would be suggesting creating different nodes for the same content.

Suppose we want to store the value "day of week", Monday, Tuesday... Sunday. We all know, surely, that the way to do this is to store a number 1 to 7 (or 0 to 6 if you prefer.) Surely nobody would suggest that we should store "Monday" in the English data storage area, "lunes" in the Spanish data storage area, and so on, up to the number of languages that we want to handle.

Well, that's it :)