Menus:
- Site building > Menus > List > Menu > [Menu item] > Add/edit [New:] Language drop-down: All languages, Lang A, Lang B...
Blocks:
- Site building > Blocks > [New:] Block language radio buttons: All languages, Lang A, Lang B
Content types: Content managagement > Content types > [Type]: Multilanguage options: Checkmarks: - Set current language as default for new content - Require language (Do not allow Language Neutral) - Lock language (Cannot be changed) These are extremely useful for user-added content!
Content:
- Content creation/edit pages: [New:] flag outdated translations. The Language options were added earlier by core.
That appears straight forward. Basically there are two options to translate these: 1) Creating new menus in the other language and have those appear in their respective language only. - or - 2) String translations, where the headings are translated in Site building > Translate interface > Search. After translation here, the system selects the translated terms for the appropriate language.
I have not been able to make Option 2 work since Drupal introduced languages. And this is where I am now. WIP...
String translations: I'm stuck at the point where I gave up several times earlier. My solution was to abandon all blocks that could not be translated with string translation and I made my own. That meant abandoning all module-created blocks, because you can't just duplicate them. But I can't do that this time, because the blocks are crucial and learning how to create them manually will take too long with the added risk of being unsuccessful. I'll have to push through with the string translations. Also, while in v5 there were some known difficulties for this, I'm now using v6, specifically for multilanguage. The main issue is the Menu/Block headings:
Analysis of translation behaviour Menus and Blocks: Handbook entry here: http://drupal.org/node/313302. This is quite short.
The option All languages is really that: the item appears in every language, regardless what language the item is written in. Selecting one language, ex: Lang A, has the item appear in that language only. Apparently the there is no option that explicitly makes an item available for string translation, like the core Language neutral with (string) translation (on content pages). It's possible that this is not needed, as i18n would be doing this already.
Menu items: All languages, Lang A, Lang B: Menus: Not translatable - but their automatically created blocks are
Blocks created automatically by Menus: All languages, Lang A, Lang B Blocks created independently: All languages, All languages (Translatable), Lang A, Lang B
The string translations of block names is inconsistent. Since the block names are related to Menu names - in many cases the headings of a list of menu items can't be translated: The name of the Language switcher block, "Languages" will appear in string translation, can be translated there and will appear in correct languages according to language paths (note that this is site-wide, the admin language tab will also be translated). But no other block will do that: Some appear in string translations, can be translated, but do not appear correctly in their lanugage (path). I also see string translations disappearing! Others will never turn up in string translations, no matter of refreshes, updates, cache clearance and cron updates. I have no idea what's going on, but this is not good. Another one of these... WIP
For new blocks that are manually created there is an option All languages (Translatable). This might refer to a string translation, not sure, I haven't worked with empty blocks yet, I don't really need them now. But does the omission of All languages (Translatable) for Menu-created blocks mean that neither those menu headings nor those block headings are translatable - as practice shows? I'm really having trouble understanding how this works.
Dead end. Time to feed the snakehead fish, and watch them for a good while.
--- 31 Oct 2009 --- Searching drupal.org. Trying to filter out older threads (they might not apply to v6) isn't working well, so I'm sifting through. Finally - a new thread: http://drupal.org/node/356375 : it appears that menu headings/blocks escape translation if they were made before the i18n was installed!!@! (this is an old duplicate of a newer thread (yes, these things are possible):
http://drupal.org/node/442428 : the translation strings disappear.
http://drupal.org/node/541048 : titles of blocks made by other modules are not translatable, string translations disappear.
String translation for blocks/menu headings does not work.
A new proposed patch by chaps2 confirmed to be ok is available since mid September (about a month ago). I came accross chaps2 and read his drupal comments earlier (5*). I can't apply the automatic patch (no SSH).
With all respect to developers, coders and designers - it is not ok to lead Drupal users into a dead end. And I really wonder how anyone else can actually make a multilingual site! That, it appears to me, is the state of things on 31 October 2009. I think I needed to say that here.
Looked into the patch. Made the changes manually. Uploaded it. It had no effect for about the first ten minutes. And then it worked. (!) It worked. Thanks Chaps2, much thanks.
Back to work.
Red ERROR: The menu name can't be longer than 27 characters.
Well. I was making the menu name shorter. What the... Ok, let's count characters... I don't have 27 characters. I have 21. In English! I'm not letting a stupid little error like that get the best of me. http://www.janroe.com/node/105 . Fixed. What's next. Which error should I fix next? Give me another error to fix!!!
Back to work. Hm... lunch is calling. I'm happy I made some headway...
I should not have asked. The string translations do seem to be working. But the Refresh button for strings will still immediately delete all translations from self-, menu- and module-created block headings. I'm certain that this should not be intended behavior. The only block heading that retains its translation is the Language switcher block heading: Language.
I need to seriously deliberate what to do now. Time to feed the fish again.
Luckily a problem crossed my way that could be solved with hands and feet, and some help from one of my factory assistants. This fish feeding time accompanied a bit of drupal contemplation, so it took much longer. Finally I noticed a juvenile, maybe 10 inch snakehead in midst of the baby tilapias. Death and destruction! Not sure how he got in there (they can jump but the area is protected, or he was still in there from the earlier batch of snakeheads, the size is about right). It did take a swim and some more to catch him and get him out. My son wanted to keep him, but was then proud to throw him back in, I must say suprisingly far for a 3-year-old - almost back into the Nile tilapias! Close call. Onlooker fan #1 fan gave a chuckle. You're very lucky, you know!
I'm going with option 2, creating all menus in separate languages, just as before. Difference from before, the module-created blocks, that don't allow language duplication, will have to be translated with string translation - which sufficiently works if I (or anyone else) never click Refresh.
The same goes for taxonomy terms - painful as it may be I'll be setting up separate taxonomy systems for the languages: Set language to vocabulary. I would have preferred a single system with translations, but clearly, the i18n string translation can't be trusted. Just imagine someone hitting a refresh button - and the entire taxonomy system disappears. In all cases, I need to study this further. [Upon further study, beware: herewith the taxonomy terms (and content categorised with it) can't toggle languages using the main language switcher; no relationship exists between them}.
Also, I'm verifying this refresh issue. I'll try to have this solved professionally. This stubborn dogged drupal user proceeds on target.
--- 31 Oct 2009 --- --- 06 Nov 2009 --- Continuing. Now:
Warning: Got a packet bigger than 'max_allowed_packet' bytes query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (3, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:1302275:\"Got a packet bigger than 'max_allowed_packet' bytes\nquery: UPDATE sessions SET uid = 3, cache = 0, hostname = '124.157.185.191', session = 'spam_form|a:42:{s:7:\\"#prefix\\";s:17402:\\"<div class=\\"preview\\"><h3>Preview trimmed version</h3><div id=\\"node-84\\" class=\\"node\\">\\n\\n \\n <h2 class=\\"node-title\\">\\n <a href=\\"/node/84\\">multilanguage internationalisation module ( in /home/[sitename]/public_html/includes/database.mysql.inc on line 128
and
Almost lost my entire content here. I know this one already (http://www.janroe.com/node/82), need to increase max_allowed_packet size, now from 8 MB to 16MB. Not enough, several iterations, 1024 MB is also not enough. The problem must lie elsewhere - maybe it's my post, it is just too long, is there a setting vor max post length somehere? Cutting this post, continue in another post: http://www.janroe.com/node/121. Well.
--- 06 Nov 2009 --- This continues from 1a: http://www.janroe.com/node/84. The last status was that that a bug would not allow tranlating most block, menu, taxonomy strings and it also deleted all string tranlations when you click refresh.
The i18n module author has checked the patches, chosen a different one from the one that I chose (there where two) and changed it: http://drupal.org/node/541048#comment-2230652, http://drupal.org/node/442428#comment-2222046. This is very good news. A full new version must be in cvs, but I've never used it. That'll be next.
Translating: Content type Classified Ad type:ed-classified:name this spec occurs twice in string search. When translated twice it gives errors:
Upon strings refresh strings:
repeated:
after removing the content of one translation, error continues: