So far a basic aspect of the model used in this module is that we set the global language to a generic two-digit language. From there, we use where we can a process where the country-specific version of translations are used if available, with the language-neutral ones used as a fallback.

This existing approach has some merits. For instance, it can minimize the need for duplication of translations--create a country-specific one only where needed.

However, it also imposes significant limitations on what can be translated. The whole point of country-code is to enable country-specific translation. But if the global language is two-digit, any country-specific translations will not be used. For example, if you create and import a fr-CA .po translation set for Drupal core and a user is browsing the site in fr from Canada, this translation set won't be used.

It may be possible through a series of workarounds and overrides to get Drupal to use country-specific translations where available, but it seems doubtful that this could be done tidily.

The alternative is to rework country code to set the global language to a country-specific version (if installed and enabled). This is, however, a major change that will have implications throughout the module.

As a step towards assessing the potential of this change, I'll work up a preliminary patch trying to at least map out the scope of the work.

CommentFileSizeAuthor
#8 country_code_country_language.patch20.58 KBrecidive
#6 country_code_country_language.patch19.04 KBrecidive
#5 country_code-country-language.patch15.3 KBnedjo
#4 country_code-country-language.patch9.05 KBnedjo
#1 country_code-country-language.patch2.93 KBnedjo

Comments

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
StatusFileSize
new country_code-country-language.patch2.93 KB

Here's what I guess the first step would be: set the global language to the country-specific version.

zroger’s picture

zroger commented

patch working as advertised, except line 140 should use $country_language_long, like 

      $language = $languages[$country_language_long];

still testing though...

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Here's an interim idea of where this is heading. Not ready for testing--will break a site.

Changes made:

1. In setting the current language, accept only country-specific versions.

2. Remove storage of country language information. Instead, determine a country's languages by looking at the list of languages and seeing which ones have the country code.

This part is only begun and requires a lot more work. Probably we still want to display the country's languages and a way to add a language to a country, but adding the language creates the language through the locale system rather than creating a record in the country language table we had previously.

Note: need to assess performance implications of joining on substrings of the languages.language field.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
StatusFileSize
new country_code-country-language.patch9.05 KB
nedjo’s picture

nedjo
he/him/his
Primary language English
commented
StatusFileSize
new country_code-country-language.patch15.3 KB

Here's a further iteration of the patch. Includes some initial work toward fixing up language adding.

Todo: A whole bunch. One minor detail that springs to mind: fix language switcher block--needs to recognize the current language and so not hard-code prefix.

recidive’s picture

recidive commented
Assigned: nedjo » recidive
Status: Active » Needs review
StatusFileSize
new country_code_country_language.patch19.04 KB

I've fixed some issues.

Only one test is failing. I didn't run tests before so don't know if it's that patch that is breaking test.

Country/language administration is working well. I did some basic test like switching countries and languages using switcher blocks, that seems to be working fine, but the current language is not being set to 'active' (don't know if it was working before).

Still to do:

- Test views filters, I haven't changed any, but this patch seems to deal only with interface translation, so it should work.
- Test country/language setting on user profiles.
- What more?

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Nice work, this is coming along well.

This code that I added in an earlier iteration of the patch seems clunky. We detect a substring, only to later concatenate it into what it originally was, the country-specific language. Shd we instead merely return that language?

[?php

+ if (empty($language_code)) {
+ if (strtolower(substr($language->language, 3)) == $country_code) {
+ $language_code = substr($language->language, 0, 2);
+ }
+ }

recidive’s picture

recidive commented
StatusFileSize
new country_code_country_language.patch20.58 KB

Updated patch, fixed a few issues on places that we use global languages.

Languages block now is marking current language as 'active'.

"This code that I added in an earlier iteration of the patch seems clunky. We detect a substring, only to later concatenate it into what it originally was, the country-specific language. Shd we instead merely return that language?"

Hmm, I tried to improve this but, there are places where we call this function with $lang_code parameter and others with both $lang_code and $country_code. Need to think more.

Now that global language is set to country specific, can we get rid of hook_date_format_languages_alter()?

stella’s picture

stella commented
Status: Needs review » Needs work

hook_date_format_languages_alter() is still needed at present, but isn't currently working due to the new changes. It's still needed as $language->language is always 'en' on my site. I think this is because it is the default language for the site and is never set to the current language.

It's not working because country_code_get_country_language() isn't quite working as expected. If you supply no arguments to it, then it always seems to return FALSE even though I know that there should be an enabled language for my country and language. Part of this is to do with the fact that this function does not work at all with the "Global" (XX) country - there is no valid '-XX', 'en-XX', etc, language. In addition, in this function, $language->language is always 'en' (regardless of current country / language), and not a 5 character language code, so if the function has to determine the language code itself, it's always empty.

Also, if I print out the configured language / country session variables in hook_date_format_languages_alter() (which is called from the date_format hook_init() function), $_SESSION['country_code_language'] appears to be set too late for it to work. For example, if my country is Canada and my language is English. I then change my language to French but my debug print of the country_code_language session variable still prints out 'en'. On the following page load, it displays 'fr'.

Finally, the language switcher block only kind of works. I can successfully switch languages, and when my country is set, it correctly displays the languages available for that country. The problem arises when you're viewing a node. On my test site I have 3 countries configured - Canada (English, French), US (English) and France (French). For the test node, I've setup a translation for each of the languages (en, fr) and for each of the country specific languages (en-CA, en-US, fr-CA, fr-FR). When viewing the node as global country, I see a list of all 6 of the available languages (as expected I think). However, when I change my country to Canada, I still see all 6 available languages. I have to click on 'Francais (ca)' to see the Canadian French version. Clicking on just 'Francais' will return the general French translation. It's kinda confusing - I think only the translations available for the current country should be displayed and they should just be labelled 'Francais' and 'English'. If Canada, and there is no 'Francais' version for fr-CA, then the 'Francais' link should return the 'fr' translation, no?

Oh and the country switcher block never shows the active country.

That one test failing is okay. It does work, just an on-going issue we have with SimpleTest. I've opened up an issue about it at http://drupal.org/node/325728

Cheers,
Stella

recidive’s picture

recidive commented

I've commited a local version of this patch, improving country_code_get_country_language() function.

stella’s picture

stella commented

The "Country fallback option" setting 'Default' doesn't work. When this is set, the current url is rewritten to e.g. "http://www.example/com//admin". All links that you then click on are in the format "http://admin" , etc. I do have a default country configured. The $_SESSION['country_code'] setting is empty.

Cheers,
Stella

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Stella, thanks, I'll work on fixing that.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Fixed the issue Stella reported.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Needs work » Needs review

Numerous further fixes applied. All identified issues fixed, but further testing needed.

Reworked views filters.

Fixed language selection when switching countries and viewing a node with translations. New behaviour: the country switcher links to the determined best translation of the node. Then, when the new page loads, that node's language is set as the default language (provided it's valid for the country). Also, when there is a language in the session, refer to it to determine the best language to set for the new country. Retain the same base language. E.g., if switching from fr-CA to global, set the language to 'fr' (if fr is installed and enabled)."

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Needs review » Needs work

Issues with path aliases. Trying to track down.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Needs work » Needs review

Aliases issue seems to be fixed by #327487: Aliases broken for translated content, re-opened.

stella’s picture

stella commented
Status: Needs review » Needs work

This version is much better. However testing has thrown up the following issue when viewing nodes.

Setup countries France, US, Canada, Netherlands
Setup global languages: fr, en, de
Language for France: fr-FR
Language for US: en-US
Languages for Canada: en-CA, fr-CA
Languages for Netherlands: en-NL, fr-NL, de-NL

If I set up a node and give it translations for each of the global langs (fr, en, de) and for the country langs fr-FR, en-CA, fr-CA, en-NL, de-NL (i.e. none for en-US and fr-NL), then node displayed for the US is the global 'en' version which is fine I think.

If I change my country to Netherlands, there are two NL translated versions of the node - en-NL and de-NL. There is no fr-NL and so the language switcher block only shows en-NL and de-NL. However, there is a global 'fr' translation, so shouldn't the language switcher block also contain a Francais link for the 'fr' translation?

If I change my country to France and view the fr-FR version, then it all works fine, except the language switcher block still appears, showing just one language (fr-FR). Shouldn't this not be visible if there's only one language for the current country?

The module works much better now, and retains knowledge of the user's current base language when switching countries, so it always displays the same base language if available for that country. Good work!

Cheers,
Stella

stella’s picture

stella commented

If I view the site in 'fr' - i.e. with Global 'xx' as my country, and French as the language, I can correctly see the French translations for the user interface, e.g. the help text on admin pages, Save buttons, etc.

If I change my country to France, my language becomes 'fr-FR' and none of the UI strings are translated. It would be nice if these could fallback to using 'fr' but I'm not sure if this will be possible, but it would prevent a large number of duplicate po files.

stella’s picture

stella commented

In views, the filters Node translation: language and Node: current country's language both work, though I do wonder if the "current country's language" should actually be part of the "Node translation" group instead....

The filter, Node: country, does not work at all. I could not make it display any nodes in my view, regardless of which country or language I choose, either via the exposed filter list or via the language / country switcher blocks. I tried the global ones too. Nothing ever appeared in my view.

The field 'Node: country' appears correctly - though if the current country is global and we're viewing a global translation (e.g. 'fr', 'en'), then the field appears empty. This is probably expected behaviour though.

Cheers,
Stella