Move country language filter to its own module
nedjo - November 3, 2008 - 18:42
| Project: | Country code |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | recidive |
| Status: | needs review |
Description
Now that we've reworked country_code to set the global language to a country-specific language (e.g., fr-CA for Canadian French), the views filter that implements a language fallback is no longer in any way country specific.
Previously, the filter detected the current country and current language and said: show me all content for the current country-language or for the current language if there is no country-language version.
Now, the filter says: show me all content for the current language (e.g., fr-CA) and as a fallback any content for a two-digit version of that language (fr). In other words, it has no direct tie to country and could be implemented separately.
#1
Yes, this needs to be done. The filter is not tied to country and so belongs in a new module.
What should we call such a module? "Views language fallback" would be descriptive but long.
#2
The patch in #325887: Lack of indexes produces hugely slow query should go into the new module.
#3
Issue #328194: Switch to all lower case language codes is also relevant. We should ensure the filter treats language codes as case insensitive.
#4
The filter should go in the "Node translation" group rather than the "Node" one.
#5
Working on this.
#6
I've moved language filter to a new module. I called it 'views language fallback' for now (name suggestions are welcome).
Patch and new module attached and need testing.
Question: do we need an upgrade path?
#7
Looks good. We should incorporate the indexes from #325887: Lack of indexes produces hugely slow query, see this patch: http://drupal.org/node/325887#comment-1090586
#8
As for updating... That would be pretty challenging, since we can't count on the new module being installed. Should we instead have a script that can be manually run?
We need to identify just what needs to be changed. I guess it's data in views tables. Possibly just a straight sql update substituting the new module's filter name?
#9
Added a .install file and hooks to create the indexes.
#10
Assigning back to me. I don't know why it got unassigned.
#11
Before posting as a contrib module, we should check in with merlinofchaos about whether this might go in Views.
#12
Posted a feature request to views queue.
#13
We can't put it in views due to the indexes - views is read only. Should it live in its own small module, or maybe the i18n package?
#14
Too specific for i18n I think. Probably this belongs in its own small module.