Translate titles of Pages in navigation menu
frpasman - September 3, 2008 - 10:55
| Project: | Language Sections |
| Version: | 6.x-1.4 |
| Component: | Documentation |
| Category: | support request |
| Priority: | normal |
| Assigned: | netgenius |
| Status: | by design |
Jump to:
Description
Hi,
I don't know if I'm just not getting this or this isn't possible,
but I really would like to have an English and Dutch title of a single page,
which also changes when you change the language, just like the body text does.
How can I do this?
Thanks in advance.
Fred.

#1
It's not possible with Language Sections because it works as an "input filter" and page titles are not passed through there by Drupal.
I am working on a module which will do it. In fact it's designed to allow on piece of text to have multiple languages (things like Views titles as well.) It works by packing the values into a single string using a special syntax.
#2
Are you talking about the title of a page shown in the page, or the menu item (because you talk about the navigation menu)? For menu items, there is an easy way for making i18n translate them (if you create a translated string), see http://drupal.org/node/313770 or http://drupal.org/node/312732.
About the page title shown in the node, I currently trying to do sth. similar as I did for menu titles in http://drupal.org/node/312732 and guess I will post another little howto for this if I get it working. Maybe that helps as a quick hack until netgenius finishes his module.
netgenius, would your module cover arbitrary strings, i.e. page titles as well as menu item titles? That would be cool...
#3
I think the original post is referring to the page title as shown when the page is viewed (full node) or shown elsewhere as a teaser or just a title. The new module I referred to - "Language Extras" works OK but there are all kinds of complications that would make it difficult to use for most people.
What seems clear is there are a few people who like the idea of a single node with multiple languages "built-in". Language Sections does that fine for the body text, but nothing else. The obvious areas that need translation are the Title and Menu entry (if any) as you have pointed out in your http://drupal.org/node/313770 - so I'll go and continue there.
#4
Maybe people are missing the main advantage of your module: node translations are only fine if you always translate complete menu trees because you cannot share menu subtrees between a node and its translation :-( With your module, the whole menu tree is always there and we show all pages in the "best we can" language :-)
About the extra language module: The breadcrumbs path should also translate, I don't know if this works automatically if the page title does.
If you are looking for a beta tester for your module before you release the first -dev, let me know! I have installed 6.x only, though, so I couldn't test for 5.x. And I'm not doing much with CKK/views, just that simple "translate my title and menu" stuff :-)
#5
Good point about breadcrumbs ... I hadn't thought of that - though no problem with "Language Extras" (the new unreleased module) because it translates *everything* by looking for what needs translating. It knows what needs translating because you store the text in a special format. For example, in a node title you might put: ::Good morning|Buenos dias|Guten Tag -- it knows that anything starting with :: means "choose the correct version of these strings, and it knows (configured) that the first is English, then Spanish, then German. The choice of marker '::' and separator '|' would be configurable too.
So as you can see, the concept is similar to Language Sections, but it will work *anywhere* (including menus.) It's not user friendly to have to store text this way, but a better UI could be added in the future (keeping the packed strings but having forms which displayed them in unpacked format for editing, then repacking them before storage.)
So OK, I'll go back to the module and see what else I need to do (not much I think) to create a usable version.
#6
Sounds great! Storing text this way *is* good, I think, because for such short strings (as would usually be), a gui might make things more complicated. But maybe it could be easier for people to use if you use similar markers as you do in language sections, i.e.:
=en=Good morning=de=Guten Tag=es=Buenos dias
or
[en]Good morning[de]Guten Tag...
Because I would bet that the problem people had with this module was remembering which order the admin setup for the languages. "He, was that spanish before german or after it?" So some language-sections-like markers might be helpful. And parsing shouldn't be that much more complicated, just that you grep the lang code between the markers. What do you think?
#7
I had originally thought about using the same format as Language Sections, and dropped the idea only because the strings would be even longer that way, and perhaps more difficult to read. There's also the complication of needing '=' in some text, so it would have to be escaped in some way, but I suppose that wouldn't happen very often. But I agree, people might forget the correct language order, or in some cases might want a different set of languages than in other cases. So OK, I'll go with the LS fromat, that way I can just call the existing LS code.
I'll go and take a look at the code in the next couple of hours, and aim to upload something later today.
#8
Well, I tried, but I need to spend more time and just don't have time at the moment, sorry. A simple solution for menu items could be a separate module, but I hoped to do more, so my module is perhaps too complex.
#9
I will happily test whatever you come up with! Menu items are the least problem because you just need to set the customized flag for menu items created in the node edit page (which I easily do in hook_form) to let i18n do it, so if your module can do anything but menu items, that's fine already ;-)
I'll just wait!
#10
Hi netgenius!
Any news from the language extras module? I still wish I could get rid of my ugly "put all translations of my fixed strings in a array variable and save it in drupal variables table" hack :-)
#11
The news is no news :) I'm 110% occupied on other things I'm afraid. Flat out with this site - www.ksfiomdepositors.org (Drupal based of course) -- 5000 visits per day (or more) since start up just a few weeks ago.
#12
Important project, I see! I wish you best luck! I was close to putting money there but then switched to a german bank with a slightly worse offer...
#13
Then you were lucky and/or sensible! Total losses represented by our members is approx 250M euros (yes, two hundred and fifty MILLION) - yet we are only some 1500 of around 9000 total. So, this is totally off-topic, I will stop.
#14
I'm getting really frustrated.
I came to Drupal from Plone because I wanted to use MySQL and I was lured by the promise of "built-in i18n support". Been struggling for days and getting nowhere.
I've been running around in circles just trying to make a test page where the title says:
" Welcome! / Bienvenidos! / Willkommen! "
and the body says:
" Welcome to mydomain.com / Bienvenidos a mydomain.com / WIllkommen auf mydomain.com "
Is this possible in the current version of Drupal (6.6)?
Evidently it can't be done using Language Sections so what's the purpose of Languages Sections?
Is there some other approach I should be using instead of Language Sections?
Doesn't seem to be much point in just translating bodies and not titles...
Is there a way to do this basis i18n task in Drupal (page titles in different languages) or am I going to have to ditch Drupal already and move to Typo3?
#15
Firstly I'd say don't ditch Drupal just yet! I did the rounds a few years ago - Plone, Typo3, Joomla, etc, and now am confident I made the right decision with Drupal. Like any system it has its good points and bad points, its way of handling multi-language sites is not a good point, but not especially bad either.
Language Sections is really designed for translating node bodies - the normal way to do that (with titles of course) is with i18n translation. Drupal expects you to have one node per language - the i18n features allow you to link them so that when switching languages the correct node is displayed. It is IMO all far less elegant than Plone, but it works ok.
The reasons why you might use LS in a node body is to say something like "Content only available in English" in various languages as part of an English language node - those messages could then be displayed in the correct language (with no such message if the user was already viewing in English.) There are many other parts of Drupal and its modules which use text passed through the "filters", and LS allows some multi-language features there which would otherwise not exist.
If you haven't already, try joining relevant Groups at http://groups.drupal.org
#16
And if you are willing to wait until negenius comes up with his languages extra module that will be doing exactly this, you could work around the problem yourself easily if you can use your own module.
Unlike using i18n as I described in http://drupal.org/node/312732 I now just use a array of strings to store translations from german to english (since I know that I will never have any other languages than those on my site). Just creating an input form and calling one function in nodeapi to store the english translation and another one on nodeapi 'view' to call drupal_set_title with, that's all. Not even a database needed since I don't have more than, say, 100 user created pages, so I store the array in drupals variable table.
I you thinkg you could go with such a temporary solution to wait for netgenius' module, let me know and I can post some code snippets.
#17
Just as an update, the multi-language site project on which I was working has been shelved, which means I'm not likely to be doing any development in this area until a new project comes up.
#18
:'-(
Would you mind to offer your work done so far for download? I would be interested to see your concept of those multi-language strings to see if I can learn sth for my own efforts (I'm currently translating page titles, menu items, breadcrumbs, and node titles in views).
#19
@Frank
Sorry it took me a long time to reply! Can't you give me the address of your site? I'd like to look at the way your using LS. Maybe I will re-start work with "Language Extras" now I have a little more time.
Why do you use LS rather than one node per language via i18n? - I know there are reasons, I'm just wondering what yourS are - is it because its always the same people who write content for all languages? Well, I see you have built your own solution now - as I've said elsewhere, I'm not sure that LS should be messing with things like node titles and menu titles - that's definitely outside the scope of an "input filter". So I'm going to close this issue. Watch Language Extras for a possible update.
#20
Our site is http://www.bio.ifi.lmu.de
The problem with i18n is that is doesn't allow to share menus. We have menu trees where multi- and single-language nodes are mixed. This is not possible with i18n. If I take a node which has 20 children in the menu tree and translate with using the translation/i18n way, the translated node will lose those 20 children until they get translated, too. This is completely unusable. Just think of a page like "Welcome to the teaching page. The main information is blabla... Please note that the subsequent pages are available in german only."
You wouldn't see any of the "subsequent pages" in the menu of this english page, even not if they were set language neutral instead of german.