Posted by andy inman on September 13, 2010 at 10:28am
Suppose some content has variants in en-GB, en-AU, etc, as well as plain en. If a user's language preference is en-GB, they should see en-GB content if available but if not they should see the standard en version. I am not aware of any way to do this with existing modules (though it wouldn't be very difficult to write.) Am I wrong? Is there some way to do this already? (with D6).
Comments
i18n module
Hi Andy,
You could declare each variant as a separate language and then use i18n module's fall back mechanism to serve the default language. Using path discrimination should also work with such language variants.
http://drupal.org/project/i18n
hth
Frank
Frank
My LinkedIn profile
Only works for a simple case
Hi Frank,
Agreed, but that will only work when the site default is a suitable language. If you need to cater for multiple languages too, it's not a solution. Sorry, I should have said this in my original post - suppose we have en-GB, en-AU, en plus es-ES, es-MX, es, and so on.
Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.
Combining with domain access?
Well, that's a different story ;-)
You might try some combination with domain access:
HowTo: Different default languages per domain/subdomain
Different default languages per subdomain
Frank
My LinkedIn profile
Interesting idea
Ok, so I think you're saying use sub-domains, one per language. Then for each sub-domain configure a default language (so en.example.com would have default language en and other languages en-gb etc.) Interesting idea, sounds like it could work. Still no solution for single domain though (the more common requirement IME.)
Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.
Sub-language discrimination by path
If I understand correctly, the solution would be an extended language discrimination by path for sub-languages like so:
with /en/ and /es/ being the fallback language in each case. Perhaps you could suggest that as a feature request in the i18n module's issue queue?
Frank
My LinkedIn profile
Yes, something like that is
Yes, something like that is what's needed. I wanted to confirm that there was no way to do it with existing modules, which is what I believed to be the case. Seems a bit strange that its not a more common requirement,
Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.
Same questions here
@netgenius: Did you have much luck finding a solution to this? I have faced the same dilemma in the past (and opted for the Domains based solution) and am facing it again with a site that needs regional/local content AND translation. There appears to be little flexibility to the i18n fallback - which looks like it could do with a more hierarchical structure.
I'd be interested to hear what you discovered.
Automatic language variants
Just re-visiting this, @admataz - sorry, I didn't see your message at the time, now more than 3 years on, I guess it's a bit late :)
I never did find a solution, and the particular client that had wanted that functionality decided not to use language variants after all, primarily because it seemed like a lot of effort for very little real benefit.
One of the ideas I started (but didn't finish) working on recently was an automatic language-variant translator, i.e. to convert "American" to "British" content and so on, extensible, of course, to other languages and variants. It worked via a combination of pspell and some user-configurable rule-sets.
Currently waiting for more free time (or a paying client!) to get that into a usable state.
Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.
"Language Fallback" module?
Looks like this has been around for a while: Language Fallback.
From its description:
I'm not sure if it covers all the places where fallback is required (nodes, menus, views), but at least it seems to avoid requiring the cumbersome multiple-domain approach suggested above.
This might be solved by module Language Hierarchy
I hadn't seen module Language Hierarchy before, looks like it was born in Nov 2013.
First of all, setup is very simple. After installing main module language_hierarchy, i18n's language management screen gets modified to enable setting up a hierarchy of languages with easy drag'n'drop handles.
I have tested the module with the following situations:
A page exists at /en/node/123. Pointing the browser to non-existent page /en-gb/node/123 falls back to using the content at /en/node/123 as expected. This uses sub-module node_translation_hierarchy.
A page exists at /en/about. Pointing the browser to non-existent page /en-gb/about falls back to the former page as expected. This uses sub-module language_hierarchy_paths (and prerequisite module pathinc).
A submodule called i18n_menu_hierarchy supports menu fallback, but at the time of writing needs a patch supplied in [#2653532]. The resulting behavior is that all menus defined in the base language (/en/) are displayed and have their links modified from /en/xxx to /en-gb/xxx.