As Drupal 7 seems to be a few months ahead, we need to start thinking how we'd like a D7 version of this module to look like. I don't mean we are beginning any upgrade yet. Also I don't think a straight code upgrade is what we want either. So this is just a thread to discuss how to do the upgrade and how to take advantage of new D7 APIs. Then at some point within the next months as D7 comes closer we may start doing and/or reviewing some code.

Though there are new APIs plenty of possibilities in D7, there hasn't been too much progress with the specific features i18n provides. These are some thoughts:

  • We should continue breaking down the package in small submodules, better if they can be enabled independently for specific features: i18nstrings, i18nvariables, etc..
  • The query rewriting (language selection) options would be better in a separate submodule that takes advantage of the new DBTNG and query tags
  • Other higher level features, like 'multilingual polls' should be taken out of this module. We are mostly interested on providing low level functionality for other modules to work with, not in specific hight level implementations like these multilingual polls can be. Any takers for this new module?
  • We need to provide a good and consistent API for other modules to have user defined translatable strings which is IMHO the single biggest missing feature in D7 for multilingual sites. This means making i18nstrings into a good API module
  • We don't want to provide an UI to translate each kind of object. We'll provide a single way to translate all strings, so people needing specific UI will be able to use any other module that suits their specific site workflow.
  • We want to get rid of ugly hacks as much as possible. This includes blocks and menus, but also integration with other modules like Views or CCK (now D7 fields). So either we get it clean or we just drop it.

Comments

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Subscribing since I maintain the xmlsitemap_i18n sub-module and I'm working on porting the XML sitemap package.

Bilmar’s picture

Bilmar commented

subscribing - looking forward to this great module in Drupal 7!
I would like to help with any testing in the future.
http://webchick.net/node/74

YK85’s picture

YK85 commented

subscribing, any eta of a d7 version of Internationalization for testing? I was unable to find a d7 ver on the Releases for Internationalization page. Thanks!

BenK’s picture

BenK commented

Subscribing....

m.sant’s picture

m.sant commented

Subscribing....

rburgundy’s picture

rburgundy commented

Update: Drupal 7.0 Alpha 2 has been released (http://drupal.org/drupal-7.0-alpha2)

YK85’s picture

YK85 commented

I was wondering if Translation module is going to replace Internationalization in Drupal 7?
http://drupal.org/project/translation

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

subscribing...

tutumlum’s picture

tutumlum commented

subscribing...

robby.smith’s picture

robby.smith commented

+1 subscribing
any plans for this in the near future?

Maikel’s picture

Maikel commented

subscribing...

greenc’s picture

greenc commented

+1

Docc’s picture

Docc commented

subscribe

manimejia’s picture

manimejia commented

I am leading development of a D7 based intranet platform. It's gonna be used in multiple countries and languages. We will need field configs (labels ect) translatable by launch time, in spring 2011. I hope to have resources available to assist in getting this module a D7 release before then.

Lots of developers are chomping at the bit for a D7 core release. Would be great if this module was ready along with it.
Please Jose, if you can, lay out the current state of your roadmap for us here. We have a small team, but are willing to help.

Thanks,
M.M.

Bodo Maass’s picture

Bodo Maass commented

subscribing

jax’s picture

jax commented

i18nvariables and i18nstrings can be implemented with the new DDT feature if I understand #593746: Prepare Drupal core for dynamic data translation correctly. In said issue they're also talking about starting a module to implement some of this but there is no reference to a specific contrib module.

Since I've noticed that the trick with the alias for a per-language front page doesn't work anymore in D7 (the alias is translated to its path) the only solution that remains is to use language dependent variables. So I think it is quite important to have i18nvariables functionality asap to be able to make even a simple multilingual site.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

D7 release date is projected in month or so (~30 critical bugs remaining)!

I know this date has changed so many times in the past, but we are getting really close now. It is a big shame that a module as important as this one (should be in core from day 1) does not even have a draft 7.x dev version available. I mean, come on... more than 23k people are using it.

bojanz’s picture

bojanz commented

@klonos
True. We await your patch eagerly.

(Talk is silver, code is gold.)

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

If talk is silver and code is gold, then what is irony/sarcasm? ...funny guy. On the other hand we both found ways to add clutter to this issue without actually helping ;)

greenc’s picture

greenc commented

I think this is supposed to be a thread about ideas for i18n in Drupal 7 ... that is, a "what" thread rather than a "when" thread ... so, here's a suggestion I'd like to add...

When translating things such as Taxonomy terms, Content Type names and descriptions, etc. I think it would be best to use the Installation language as the source for the "Original text" rather than the Default language. The former seems to be the strongest indicator of the language in which one would like the admin interface.

We have a multilingual site in English and Spanish installed in English but defaulted to Spanish (so Spanish is the primary language for users and the home page and English secondary /en). The reason is that we are native English speakers developing sites primarily for Spanish language audiences and like the backend and original text in English. Translating gets a bit confusing as sometimes English is the Original text and sometimes Spanish, so it has the vague feel of disorder and makes it problematic to use the same codebase (installation) for sites in other primary (default) languages.

Locale, on the other hand, always seems to use English as the source of the Original text. I did a test (in D6) installing a site in Spanish and selecting Spanish as the default and... the Original text was still English. So the core seems to be at the other extreme.

I think it would be ideal to have all parties concerned use the installation language as the source language for the Original text for translations, taxonomies, etc. or for there to be a global admin language setting (backend) along with the Default option (front end) in Locale. That's probably not going to happen so I suppose the next best thing would be for i18n to use the installation language since the module appears to be a blank slate at this moment for D7. That would give folks in our situation a few more options.

If there are reasons that this is not possible that are obvious but of which I'm unaware, my apologies, but using Installation language as the base language seems like a good compromise.

jax’s picture

jax commented

Maybe the ideal is to be able to choose which language is the source language for dynamic strings (= taxonomy terms, labels, etc.)? For normal interface strings, the ones passed through t(), English will always be the source language.

greenc’s picture

greenc commented

That sounds great, maybe in config/regional/language/overview an additional radio button could be added for the "admin" language that would establish the language for all the dynamic strings.

Yeah, I understand why the core needs to have a consistent language and that in order to completely localize it, the core itself would need to be available in different versions on a per language basis rather than just dropping a file into the root for an installation language... and that that would be a lot to maintain, though arguably could be worth in a few of the major languages like Chinese, Spanish, French, etc..

Anyhow, I hope this idea is considered for the next iteration of i18n... it would be great to be able to change the default (front end) language around without causing a chaos.

jose reyero’s picture

jose reyero commented
Version: master » 7.x-1.x-dev

I think we are at the point to start the upgrade so created a 7.x branch. After talking with some people I think the best approach would be starting by the basic APIs, then worry about UI etc.

On a first stage we need to have the basic API modules, ideally independent so they don't need each other and you can use them for other approaches like translatable fields, which are being developed somewhere else.
- i18nvariable (all the variable stuff)
- i18nstrings (strings, texgroups, etc)
- i18nselect (content selection by query altering)

Then on a second stage, we'll see about which other modules need to be upgraded which ones are to be dropped. To be upgraded:
- i18ntaxonomy
- i18nmenu
- i18nblocks
..............

Though maybe we can build more generic modules that can translate new D7 objects, like:
- i18nfield, for fieldable entities (names and descriptions)
- i18n entity, for entity translation

We also need to keep an eye on these, trying to build APIs compatible with whatever is developed there:
- #593746: Prepare Drupal core for dynamic data translation
- http://drupal.org/project/translation

hswong3i’s picture

hswong3i commented

subscribing

steinmb’s picture

steinmb commented

Able to help out testing the code, subscribing

osbBerl’s picture

osbBerl commented

subscribing

hass’s picture

hass commented

+

miro_dietiker’s picture

miro_dietiker
Location Switzerland
commented

I'd like to refer to this discussion in translation group:
http://groups.drupal.org/node/94549
I added my thoughts about architecture.

I think we should not only port i18n to D7 but avoid some mistakes we previously did.
I really hope there will be enough people with strong interest in a clean i18n module to push this development to a cleaner solution. This is the last chance to make it fundamentally better for D7.

It's a pity we don't have more support and funds from bigger international projects to improve the situation.

mgifford’s picture

mgifford
he/him
Primary language English
commented

Ok, so where are we with this plan? We're now at 7.0-rc1. Many see this as a critical module for many D7 sites. Who is leading the charge for i18n in D7?

jose reyero’s picture

jose reyero commented
Issue tags: +d7upgrade

Adding tag

kars-t’s picture

kars-t commented

subscribe

sthzg’s picture

sthzg commented

subscribe

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented

i just had a good read http://groups.drupal.org/node/111404

emagus’s picture

emagus commented

subscribe

izkreny’s picture

izkreny commented

subscribe

wasare’s picture

wasare commented

+1

tsvenson’s picture

tsvenson commented

Subscribe

Dahliz91’s picture

Dahliz91 commented

subscribe

anavarre’s picture

anavarre
Primary language French
Location 🇪🇺
commented

Subscribe

cestmoi’s picture

cestmoi commented

subscribing

dsoares’s picture

dsoares commented

subscribe

finex’s picture

finex commented

subscribe

idflood’s picture

idflood commented

subscribe

gobioasis’s picture

gobioasis commented

subscribe

acemi’s picture

acemi commented

subscribe

Taxoman’s picture

Taxoman commented

Subscribing.

mlecha’s picture

mlecha commented

subscribe

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Status: Active » Fixed

Alpha1 now available: http://drupal.org/node/1023334 (I think we can mark this fixed and let people submit individual issues, which they already do).

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

Perfect! Thanx ;)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

petsagouris’s picture

petsagouris commented

subscribing