Drupal: multilanguage internationalisation module (i18n) - intro

Created by janroe

drupal internationalisation module (i18n)
http://drupal.org/project/i18n 6.x-1.1 on 6.14, updating Fri, 10 Aug 2012 for i18n 6.x-1.10 on drupal 6.25, update in process

Main function:
The internationalisation module provides additional support to translating interface and content. In order to have a multilingual site, you probably can't do without it.

The 6.x core supports the translation of the interface, basically that is all admin, and provides a system of translating content generated in the content types. The core does not provide a system for translating blocks, menu's, content related instructions, polls, profiles, taxonomy, views. It also does not provide for translating things defined as "variables", that is user input entered into places like site name, slogan, mission, footer, the all-important contact page text, and so on.

Example function:
i18n supports to make an intended multilingual site fully multilingual.

Components:
Module components are: Block translation, CCK translation, Content type translation, Internationalisation (=main), Menu translation, Poll aggregate, Profile translation, String translation, Synchronise translations, Taxonomy translation. Earlier included Views translation is now separate (i18nviews module).

Manage:
The purpose right now is to give a quick overview of selections available from this module, without going into detail. Details are explained in further texts.

First, check your permissions page, User management > Permissions.

The drupal i18n module does not create an admin heading if its own, it integrates into language/translation sections of Site building, Site configuration and other components. Note that whatever appears depends on which i18n sub modules you have enabled. For example, no reference to taxonomy appears it you did not enable i18n taxonomy.:

Main

  • Site building > Translate interface > Search: Limit search to: Blocks, Content type, Menu, Profile, Taxonomy
  • Site building > Translate interface > Refresh: Refresh strings for Blocks, Content type, Menu, Profile, Taxonomy; Update translations for check marked languages.
  • Site configuration > Languages > Multilingual system:
    • Content selection modes: Radiobuttons (select one):
      • Current language and language neutral
      • Mixed current language (if available) or default language (if not) and language neutral
      • Only default language and language neutral
      • Only current language
      • All content, no language conditions apply.
    • Content translation links: Checkmarks:
      • Hide content translation links (on page language switching)
      • Switch interface for translating

Some of these terms are not immediately clear. I wondered at first if "mixed current language (if available)" might refer to the way my son and I talk with each other, mixed Thai, Lao, Dutch and English. Or could it be some sort of slang? Users might have some trouble following...

Menus:

  • Site building > Menus > Add menu (tab): - none
  • Site building > Menus > Edit menu (tab): - none
  • Site building > Menus > [Menu name] > List items (tab) > [Menu item name] edit (in text): Language: Drop down box (select one}: - All languages - Lang A - Lang B

Note: Menus create blocks. Language behaviour is configured there. Individual menu items do have language characteristics and can be made to behave according to them.

Blocks:

  • Site building > Blocks > Add block (tab): Multilingual settings: Language:
    Radiobuttons (select one):
    - All languages
    - All languages (Translatable)
    - Lang A
    - Lang B
  • Site building > Blocks: [Block name] > configure (in text): Mulilingual settings: Language:
    Radiobuttons (select one):
    - All languages
    - Lang A
    - Lang B

Note: The above are two different types of blocks. First (add) block is custom made, second (configure) block is menu or module made. They have different language characteristics, ramifications not entirely clear (string translation?).

Content types:

  • Content management > Content types > [Type]: Multilanguage options:

    • Options for node language: (super !!!)
      Checkmarks (check any or all): 
      - 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 shaping user-added content!
    • Extended language support:
      Radio buttons (check one):
      - Normal - All enabled languages will be allowed.
      - Extended - All defined languages will be allowed.
      - Extended, but not displayed - All defined languages will be allowed for input, but not displayed in links.
    • Synchronize translations:
      Checkmarks (check any or all):
      - Author
      - Status
      - Promote
      - Moderate
      - Sticky
      - Revision (Create also new revision for translations)
      - Book outline (with the translated parent)
      - Taxonomy terms
      - Comment settings

    Content:

    • Content creation/edit pages: [New:] flag outdated translations. The other Language selection options were added earlier by core.

    Cannot set a path prefix for default language

    To be more precise, you can set it, and it will work, but the language switcher does not follow this path. So it's for the greatest part useless. In detail:

    In Admin > Settings > Language: Languages > edit, you set the Language name in local language, original language, and set the language path prefix, such as example.com/en/node/1.

    This works fine with core locale and content translation, regardless of what your default language is. Meaning, you can set a path for both the default language and any other language, and the language switcher follows those exact paths.

    As soon as i18n is enabled, the path prefix for the default language, if you have set one, disappears. If you put it back in, the example.com/en/node/1 path will work, but the language switcher won't follow it. With i18n enabled, the language switcher always follows the path without prefix for the default language. This is different from core behaviour.

    Core does one thing, the module does another. The Twist.

    If you put the "en" for default back in you have:
    example.com/node/1 (default language, switcher, but should not be doing this)
    example.com/en/node/1 (default language, switcher not working)
    example.com/nl/node/3 (non-default language, switcher)

    I understand that the developers of the module would consider this the intended behaviour. However there are many circumstances under which you would want to turn this around, that is default language with path prefix and one other language without the path prefix.

    This goes especially for English language developers and maintainers for a site with mainly other language users. The developer and maintainer needs English to administer the site and its users need a path without the prefix.

    The issue is described here. Apparently it was or still is an issue for core, but it's marked as fixed: http://drupal.org/node/244162

    And then it reappears again, not clear if this for core or i18n
    In the end, and in the end refers right back to the supposedly fixed issue in core, while not addressing the OP's problem - same as mine: http://drupal.org/node/1001916

    Apparently this remains unsolved in 2012.

    Two workarounds that might not be so great:
    - Set up the site localised in the main users' language, add/re-establish English as a second language and develop and maintain the site in non-default English. In the past I learned that administering a site in non-default language sooner or later leads to a major problem - which usually required a reinstall.

    - A cumbersome solution is to install the site localised in the other language and make sure the admin section does not get translated. This actually requires a split between admin language and user language, which is probably more difficult to do than changing (optionally) the behaviour of the language switcher.

    Misunderstanding?
    There may be a misunderstanding about the cause. If I recall my steps correctly, core did this fine and the issue came up immediately after installing i18n. Maybe i18n behaviour has not yet followed the core fix?

    After all this in-depth analysis, the problem remains. How do I set up my site now? I'd really appreciate a good tip.

    Related

    The menu item "dupal antiques" has further i18n topics. While they are outdated, they may still have relevant information.