internationalization

Hi all,

hope this is not a traited point...

I'm french and i used drupal for making an I18n website.

My pb is that one time i make my code (in english) and translate it into languages, if i make a change on english transatable string, i have to retranslate, and upload, corresponding string for all other language.

Exemple:
t("how stupide is that")
---french >>> C'est stupide
---spanich >>> Esto es estúpido

Now let suppose for optimise my english web page i want to change it to "this is stupide"
t("this is stupide")
---french >>> lose
---spanich >>> lose

Hello,

I built a website for a client in English - all worked fine. But when we added the multilingual module (i18n) (for Spanish and German translations) and enabled Views Translations we had an unexpected issue- which only affects anonymous users - no problem for authenticated users.

Languages are resolved to unique domain names: English is www."websitename".com, Spanish is es."websitename".com and German is de."websitename".com. The default language is English.

The primary issue is with "language fallback" failing when the i18n language configuration is set to "Domain name only." This happens in most A-grade browsers. German is the specific translation we're dealing with...

This topic seems to cover the general problem:" language_from_browser() doesn't parse language tags correctly, has a broken logic"

http://drupal.org/node/221712
Component: language system

Perhaps the patch will work, and I'm trying to find out if there's a release to fix this asap. Can anyone help ($$) in the meantime?

I think we should learn something from WPML Multilingual CMS plugin for wordpress. Yesterday I made site that was too simple for Drupal in Wordpress and at the last moment client asked for multi language support. My hands went cold. Used WPML and was surprised how easy, fast and simple process was comparing to Drupal - most importantly because of KISS aproach to many parts of plugin and how it works.

While currently the majority of Drupal people speak English as a native or second language, I think it would artificially limit the scope of the LUGO group to require it. I deliberately did not choose a language when I created this group because there was not an 'all' option. The audience and membership of this group is intended to be anyone, anywhere, who organizes a local Drupal User Group currently, or wants to start one. If we are going to encourage that second group to become part of the first, we will need to accommodate people that do not speak English at all.

Even though English in not a problem for me, I understand the importance and need to offer a website in other languages, so I really like that the new design have that in mind. Particularly as it also means that the internationalisation support for Drupal is moving up a few notches in priority.

Before I go into the main topic of this post, a little note about the placement of the language select. In the mockup (iteration 11), the select language listbox is placed at the bottom. I think it should actually be placed in the header instead as that will make it much easier to find. Especially those, who's English is not very good tend to leave if they don't find a language quickly without having to scroll to the bottom of a very long page. They could also be shown as flags.

Oki, back to topic. I have one site I am using the Internationalization modules in and it works just fine. The only real issue though is that browsing modules and other add-on stuff and finding information on what languages they are available in is not very easy. In most cases I have to actually download the module and check if it supports translations and if so if it is available in the language(s) I need.

So it got me thinking a bit about how this can be improved on drupal.org and I came up with the following. I will use modules as example, but I believe similar features can be applied on other areas as well, such as themes.

A report back from the virtual code sprint on internationalization in Drupal core

What if the new Fields API in Drupal core could be used in multiple languages, so that any object type could be internationalized just by adding fields?

That's exactly what the "multilingual fields" patch currently being developed would make possible.

Multilingual fields is one of two major improvements to Drupal core's multilingual support to come out of the recent code sprint on internationalization.

Ich sehe ein riesen Problem im Core und würde gern wissen ob und wie ihr es gelöst habt:

Hi,

The translation of content and textual strings has much improved in Drupal 6.
However one problem that keeps popping up for most of our clients, is the translation of menus.

Most of the solutions regarding translatable menus involve having multiple menus / blocks (one per language) set up, and show them conditionally based on the current language.
However for most of our clients that's not an ideal solution. For them having to add an item to the menu multiple times is counter-intuitive.

Anyone pulling out their hair over multilingual sites should take a look at this:

http://www.lullabot.com/articles/making-attachments-appear-across-transl...