internationalization

Hello,

I am currently setting up a multi-country / multi-language site, using one database and one code base. The reason for this is that 90 percent of the content will be shared. I will use 5 different domains for all the countries, using the domain access module package. All domains should have a different default language.

Hi,

I've set up a site in Italian at www.[mydomain].com/it (www.[mydomain].com is not a Drupal site), I have the equivalent content in German and am trying to set up a language selector to select between the languages.

If I select the “Path prefix only” option on the language configuration page, would it make the German content to show at www.[mydomain].com/it/de instead of www.[mydomain].com/de?

For the Italian site, the homepage was created as a template (page-front.tpl.php), what should I do for the German version? [I guess I can search online for this]

Hi, folks!
Has anyone worked with Translations in Drupal 6? I'm looking for some pointers..

Thanks, Mary Edith

I am working on a website that ultimately will be available in several languages. It is also going to have a lot of complex CCK content types.

A lot of these fields will be CCK options fields, such as checkboxes, radio buttons and so on. Many of these fields will be usable for filtering and creating lists as well. Some of these options will be added to as the site grows.

What I have been thinking about is the best way to implement this to be flexible, efficient and at the same time make it easy to maintain and translations.

As I see it I have two options:

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.

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.