| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | language system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | i18n sprint |
Issue Summary
Some sites will choose to create custom languages, e.g., fr-ca for Canadian French.
Generally, no core or contrib translation files are available for such languages. So the workflow in this case would involve manually importing all needed 'fr' language files. Even if they exist, country-specific translation files may be less complete than the generic two-digit versions.
An improved implementation might follow what we do in language_from_browser()--that is, fall back to two digit languages if there is no support for one that specifies a region.
Specifically:
import fr-ca if present. Then import fr if present, with overwrite set to false.
With this approach, no manual import would be needed. If there were no fr-ca translation file, the fr one would be used. And fr-ca translation files could have just the strings needed, with the rest being pulled in from fr.
Comments
#1
Seems like this would be great for country-specific translations - i.e. it's a valid use case to have en-gb as a language for UK spellings, but there's only going to be a handful of strings changed compared to core, other languages are likely to have much the same issues.
#2
I'll better make this work this way:
- import the most specific language
- then import the less specific one, without overriding strings already loaded
That would allow the "French (Quebec)" translation to only override the "French (Standard)" one on an handful of strings.
#3
@Damien Tournoud: Yes!
Here's a draft patch. I've done only very basic testing.
The changes are fairly minor. When importing translation files, we look first for translations in the specified languages and then for their two-digit fallbacks. Automated translation already uses LOCALE_IMPORT_KEEP, so the fallback language strings don't override any that were found for the original language.
#4
The last submitted patch failed testing.
#5
#6
subscribing
#7
This is a reroll, locale.inc was altered a bit.
It seems the method for querying was switched from using db_query to execute() just before the meat of the first hunk.
#8
The last submitted patch failed testing.
#9
Re-rerolled, also got rid of a db_fetch_object() since we can foreach over result sets now.
#10
I can't get this to work, but maybe I'm doing things in the wrong order. Perhaps you could provide some steps on how to test this?
#11
I think he idea of language fallbacks is ok though you cannot always make the assumption of the fallback being the two letter code. I.e. my fallback chain may be like en_CA -> en_US -> en
Other times you may want no fallback at all, as processing fallbacks may slow down page rendering.
So maybe the first step here would be to add an (optional) 'fallback' field to the language table. Then we can use it for localization, content or whatever..
#12
The fallback is pre-processed. There is no impact on the page rendering.
#13
@Damien,
> The fallback is pre-processed. There is no impact on the page rendering.
Yes, you're right. Not if we use it for importing translations only.
However there may be other uses for language fallbacks. What about real time fallbacks for string translation or if we end up implmementing translation for user defined strings, or searching for alternate content? Another case in which we can use fallbacks is.
Anyway, I have to admit this patch as it is, is an important improvement on what we currently have. I'd just like to see a better generic implementation of fallbacks so we can use it later for other things.
#14
The last submitted patch failed testing.
#15
Patch re-roll against latest HEAD, but fails a number of 'locale' simpletests, so leaving at CNW.
#16
Here a patch with some minor fixes. I've drafted simple tests to go with it, but they need to wait on a follow-up patch in #369229: Review locale module's simple tests.
#17
Can you post the simple tests too and I'll test them in conjunction with the other issue? I can confirm the existing tests pass with the new patch.
#18
Here is a version including the latest patch at #369229: Review locale module's simple tests, which is required for the simpletests here to work (since they require a .po file introduced by that patch).
I'll update this patch once #369229 is in.
#19
Re-roll against latest HEAD. All tests pass.
#20
The last submitted patch failed testing.
#21
#22
The last submitted patch failed testing.
#23
this needs to wait until 8.x
#24
In a custom solution I built on Drupal 6 I also too the approach of 'topping up' a small set of localised strings with strings from a more fully-localised language. In my case, I had been asked to allow the fallback language to be (linguistically) unrelated to the primary language, the typical use case being that the fallback language would be a language of wider communication (regional, trade, national languages, etc) that would typically also be comprehensible to speakers of the primary language. I kept track of which strings were actually in the primary language, so that updates to the fallback language could be incorporated, and to make it easy to see which strings had not yet been localised in the primary language.
I never felt completely happy with a solution that had basically contaminated a localisation set with strings that were in a different language.
For Drupal 7 I proposed, and have had some success in testing, a different solution which modifies the operation of the locale() function. I had one approach but Gábor suggested a smarter one: the use of an object, pretending to be an array, that is assigned to $conf['locale_custom_strings_$langcode'] during the bootstrap. This probably has an impact on page-load time initially, but it does then allow the results to be cached in the standard locale cache, so that there should be no ongoing extra burden.
My thoughts are initially documented in the following issues, though I haven't yet posted the complete working module anywhere - I can do so if anyone is interested in this approach. I'd also be interested to read thoughts on which of my two design options is best (or at least, better) practice - as described in the second of these issues:
http://drupal.org/node/1261034
http://drupal.org/node/1266882