Translation of node title

Can be done, though I'm not sure I agree that only nodes using Language Sections should have their menu items translated. For example, an image node might have no text (so no LS) but need a translated menu item. Could we get the i18n people to add "Multi-language" as an option rather than "No Language" and in that case the trigger the menu translation? Or maybe offer it to them as a patch - it should be easily backward compatible with existing installations. This approach seems better to me, since a node which uses LS is not really a no language node, it is a multi-language node. Also, this way, LS can stay as it is, an Input Filter, without it needing to know or care whether it's working with a Node or some other text (Views, other modules text, etc.)

Perhaps off topic, but here are some further ideas, coming from the fact that there is a need to translate both the page title and the menu items in order to have a "multi-language" node somehow packed into a single node.

A "multi-language" node needs...

1. A way of entering text (node body) in several languages and having the correct language displayed to the user - OK, Language Sections in its current form seems to work nicely for this.
2. A way of entering a Page Title (node title) in several languages. No solution currently.
3. A way of entering Menu text in several languages - you have a partial solution for this, needs a patch to LS or i18n.
4. Maybe, some intelligent handling of links within the text - see http://groups.drupal.org/node/13824
5. Anything else? (process CCK fields somehow?)

A while ago I ran a poll here - http://groups.drupal.org/node/12596 - which indicates that only around a third of "multi-language" sites need more than 3 languages, and more than a third of them (39%) need just two languages. So, a large proportion of sites need just two or three languages. This opens up the possibility of a solution designed to handle "a few" languages only - something like Language Sections but with more power.

While I appreciate that all these points would be great to develop in the long term, I have an urgent need to simply have the same kind of functionality of Language Sections that will allow me to change title fields. I would be prepared to use a "hack" for this but would also potentially be able to put forward a bounty for it's development. Could either of you help with either of these? (Frank you mention in another thread you have so code snippets you could post?)

I also am using only 2 languages - English (default) and French and am having problems as we want all languages to be able to see the same group posts in OG, and to add comments to the same comments section at the bottom of posts. We may add a third language (Arabic) at a later date but this is TBC.

If you can help it would be greatly appreciated but I'm really really on a tight timescale!

Thanks,

Adam

Although this is beyond the scope of the original design concept of Language Sections, I guess it would make a lot of sense to add this functionality. It would not be a lot of work, a few hours maybe.

The issue here is that Language Sections operates as an "input filter". But to translate a node title requires hooking into Drupal's node API, so that the title translation can take place during node load. This is no big deal, but a fundamental change (or addition) to the way LS works.

Two basic approaches:

1. "Pack" multiple titles into the current title field. e.g. Title: Happy Christmas//Feliz Nevidad//(etc.)
... I am using // as an example separator here - this would require a "language order" to be defined and known to all authors. Alternatively, something like: =en=Merry Christmas=es=Feliz Navidad (etc) like Language Sections currently. More flexible but maybe not so easy to type.

This approach would be straightforward to code, but some third party modules might show the full packed title rather than the translated version.

2. Keep title translations separately, i.e. a separate table/column in the database. More complex, arguably more elegant - more coding, database and node form changes. Any third party modules which accessed the title directly rather than via node API would probably just show the original version of the title (English or primary language.) There is the existing #translate module which I could not get to work properly but which I think would do this for you.

So, personally I think LS should to take approach #1 rather than #2 - the idea of "packed translations" would be consistent with how LS currently works for node body and other text.

Do you use comment titles? I am not sure how they are handled in Drupal. Above I am talking about node titles, not comment titles.

We can talk about funding - I'm really very busy currently, with a lot of "non-profit" work (i.e. unpaid!), so really don't have time for doing "free" stuff at the moment, sorry. Please feel free to make me an offer!

There will be similar issues with more than one 3rd party module no doubt. Did you hook in to the node API (node load)? I would hope that most modules would use that, and so compatibility may be quite good. If you have hooked via form-modify, compatibility would be less. Well, I haven't tried it, this is what I think.

This feature doesn't really "fit" in LS because LS is an input filter, and not necessarily dealing with nodes. Did you look at the #translatable module? It seems to me that they had the right ideas, but I could never get the module to work.

The way I got around this was simply to use a field "French Title" using CCK and then using my templates to display either the english or french title depending on the user's language. However as you can imagine this is a very dirty hack - but works for what we need on this occassion. The site we're working on at the moment is a loss-leader and so is low budget, but with the potential of some significant development in the future with a reasonably substantial budget.

I really love the internationalization module as it stands and use it with no problems with a lot of the site above, but the issue of having different set of comments on the translations is really where my problem lies. If we have investment I would be fully prepared to sponsor the development of a tidy end-user friendly module that creates a way of dealing with this.

This may involve having multiple translations directly within certain node type edit pages or it could be another solution that I/we didn't think of yet! So this may live outside of the way LS works or it may not (just to be clear I'm not a programming expert by any means!).

I would be interested in whether:

a) this fits in with what you are discussing here
b) if either of you would be interested in taking this further
c) how integrated into drupal and contributed modules we could make this

I'm quite new at the "market-place" of Drupal so any advice/ideas would be greatly received!

Thanks,

Adam

Finally I got round to looking at the issue queue!

To summarise - how can we translate node titles in a simple way? Here are some possibilities:

1. Pack multiple titles into the standard title field using something like Welcome|Bienvenido

2. Use CCK to store titles for other languages. It would mean that CCK must be installed (no big deal, surely almost everyone has CCK installed?)

3. Similar to (2) but use our own custom fields in the database instead of CCK, alter the node node edit form to allow them to be edited.

4. Store titles in the *body* of the node. This might seem messy, however, Language Sections node bodies are arguably messy anyway. So what I mean is, update LS syntax to handle something like:

=== en ===
Title: Welcome
Hi and thanks for visiting...
=== es ===
Title: Bienvenido
Hola y gracias por la visita...

... So, this doesn't need CCK and doesn't need any custom database changes. If some module displays or processes the node body without going through nodeapi it will see the [Title] in there, but that probably won't matter.

In all cases, pull out the correct title via hook_nodeapi. I think this should work with other modules such as PathAuto and Views, but of course won't work for anything other than nodes. A further module could be used to do form_alter on the node edit form to present a better UI for editing body text and title per language.

All that said, I did not imagine that LS would often be used for node bodies (i18n would be the normal solution) and I am not sure if this whole issue is really within the design scope of LS.

Hi,

Anyway, could someone submit a node_load() patch code. Or just a way of work.

Jurgen

PS. After that I´m still looking for a language dependent path alias.

Better idea, maybe - Change LS syntax for titles so that it works like this:

=== en: This is the Title in English ===
Here is some English
=== de: This is the Title in German ===
Here is some German

I think that's better than my suggestion in #9 - any comments?

If we're *not* dealing with a node but a title is specified in this way, then should we call drupal_set_title() to set the page title accordingly?

@Frank, did you ever look at the #translatable module - it might be a better solution. Re. CCK, it allows you to store other data types in a node, i.e. not just Title and Body but (for example) a date, an email address, etc. If your nodes are just standard posts, you don't need it.

Sorry, I forgot that #translatable was only for D5. Well, after reviewing all the above, I still think that my suggestion in #11 is quite good, though I agree with your points in 12. Nonetheless, avoiding confusion could be done by something like:

Node body...

=== en: Title in English ===
(and optionally some introductory English text)

=== de: Title in German ===
(and optionally some introductory German text)

=== en ===
Main text in English

=== de ===
Main text in German

(etc)

I still think that a more generic solution (one which worked with Views, etc.) is outside the scope of LS.

Please see http://drupal.org/node/361069#comment-2472030 - in short, I think the right way to add this feature is with a spearate module, not in LS itself.

Please, just a question. Are you going to implement this solution you suggested?

=== en: Title in English ===
(and optionally some introductory English text)

=== de: Title in German ===
(and optionally some introductory German text)

=== en ===
Main text in English

=== de ===
Main text in German

That would be ideal! Must I understand by your last reply that this is not in the scope of the filter?

I'm not sure!!! Elsewhere - http://drupal.org/node/361069#comment-2472030 - I said LS needs to stay short and sweet, and not get involved with translation of anything other than text fields. Ok, that said, a simple way to change the node title does seem like a useful feature, so I'm conflicted :)

I like the idea in #11 - it seems easy to use (easy to input text and title into a node body). Technically however it's a bit of a mess:

1. LS doesn't know about nodes, it doesn't know whether the text it's being asked to process is a node body, and it doesn't know the node id in that case. So the solution would need to change the way LS works, well beyond a simple "input filter".

2. As Frank points out in #12, there is the PathAuto module to consider. It's very widely used - it sets a url for a node based on the node title. So for PathAuto to work properly, we would need to set the node title during creation of a node, not just display. But there would be multiple titles, so PathAuto would need to create multiple urls. A node title "Good Morning" might get a url of www.mysite.com/en/good-morning and the Spanish version would be at www.mysite.com/es/buenos-dias. To make this work would require some tight integration with PathAuto, and quite possibly need supporting changes to the PathAuto module. Alternatively, we just say that PathAuto won't work, and the same for other modules that look and node title - they will see the original node title only.

Anyway, I can see the benefit of having a solution, even if it's only a partial solution which doesn't work with PathAuto etc.

Here's a question:

Why are we even having this discussion!? What I mean is, why are people not using full node translation system? Is it because "multi-language" nodes facilitated by LS are just easier/faster to work with than creating multiple nodes, one per translation? I ask because, maybe what's really needed is a more streamlined UI for the standard Drupal node translation system, rather than a "better" Language Sections module. Maybe simply a module like LS which processes text in the way described in #11, then creates multiple nodes, one per language, with titles, bodies, paths, menu items, etc, as required. It would also need to be able to "pack" those nodes back into text again so that editing could be done. So with this we would have the best of both worlds - the quick and easy way of creating and editing node content, and all the features of the full translation system. Thoughts?

I don't know if this is the good place to have this discussion. I have been trying this module, which works really well, and I agree with you that there is some complex matter here. At first I didn't like the idea of multiplying nodes. In fact, if there are some CCK node relations for example this can cause relations to break or at least to behave weird. If one is using imagefields the node multiplying can have strange effects. I don't know why we can't have just one node and multiply fields for each language instead of multiplying the nodes. But this would be an i18n discussion.

On the other hand, if I talk about language sections, it is a medium solution. One can translate texts but keywords will still be pending, and for good SEO techniques this is a problem. Maybe i18n designers multipled nodes as a way to have each node properly represented, with all its contents. But node multiplying has disadvantages. Language sections solves some of these disadvantages but not all. Problems still exist.

In my oppinion, it would be more proper to multiply node fields for each language. I don't know why they didn't choose this solution.

@Ferreres - you're right, this is not the right place :) So, I asked the same question here: http://groups.drupal.org/node/47966

Thinking about a node having multiple fields, one per language - this would be my preferred solution too. I see language as a user-preference. I might want to view a node in English, or I might want to view it in pink, or using the Garland theme. In all cases it's the same content, just displayed differently.

http://drupal.org/project/ls_extras provides a way to translate node titles.