Posted by Jose Reyero on September 21, 2009 at 4:49pm
42 followers
Jump to:
| Project: | Internationalization |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Jose Reyero |
| Status: | closed (fixed) |
| Issue tags: | d7upgrade |
Issue Summary
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
#1
Subscribing since I maintain the xmlsitemap_i18n sub-module and I'm working on porting the XML sitemap package.
#2
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
#3
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!
#4
Subscribing....
#5
Subscribing....
#6
Update: Drupal 7.0 Alpha 2 has been released (http://drupal.org/drupal-7.0-alpha2)
#7
I was wondering if Translation module is going to replace Internationalization in Drupal 7?
http://drupal.org/project/translation
#8
subscribing...
#9
subscribing...
#10
+1 subscribing
any plans for this in the near future?
#11
subscribing...
#12
+1
#13
subscribe
#14
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.
#15
subscribing
#16
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.
#17
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.
#18
@klonos
True. We await your patch eagerly.
(Talk is silver, code is gold.)
#19
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 ;)
#20
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.
#21
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.
#22
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.
#23
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
#24
subscribing
#25
Able to help out testing the code, subscribing
#26
subscribing
#27
+
#28
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.
#29
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?
#30
Adding tag
#31
subscribe
#32
subscribe
#33
i just had a good read http://groups.drupal.org/node/111404
#34
subscribe
#35
subscribe
#36
+1
#37
Subscribe
#38
subscribe
#39
Subscribe
#40
subscribing
#41
subscribe
#42
subscribe
#43
subscribe
#44
subscribe
#45
subscribe
#46
Subscribing.
#47
subscribe
#48
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).
#49
Perfect! Thanx ;)
#50
Automatically closed -- issue fixed for 2 weeks with no activity.
#51
subscribing