Posted by nedjo on January 8, 2009 at 11:26pm
7 followers
| Project: | Views |
| Version: | 6.x-2.x-dev |
| Component: | Views Data |
| Category: | feature request |
| Priority: | normal |
| Assigned: | nedjo |
| Status: | closed (fixed) |
| Issue tags: | i18n sprint |
Issue Summary
I'm working on a patch to expose the locale tables to views.
Comments
#1
#2
Patch attached.
This patch adds a new base table,locales_source, and a linked table, locales_target.
Handlers are in two groups, "Locale source" and "Locale target". All fields in the two tables are exposed.
To test:
Setup:
1. Install Locale module and i18nmenu.
2. Enable languages 'fr' and 'sp'.
3. Import one or more 'fr' translations.
4. Create two custom menu items in the primary links navigation menu.
View construction:
1. Create a new view of type "Locale source".
2. Add all fields from the Locale source and Locale target groups. Ensure that the displayed values make sens.
3. Add and test each filter in turn. Of note:
* For 'groups' filter, the options should display the human-readable labels of the locale groups
* The 'version' filter should offer the "current installed version" as an option as well as all versions registered in the DB. These should be values like 6.8 for Drupal 6.8.
4. Add and test each argument in turn. Create a page display, give it a path, and select different options when arguments are missing. Of note:
* The 'group' argument includes a custom handler so needs extra testing. or the 'group' argument, try a summary view and ensure the groups are displayed in human-readable form.
5. Add and test the relationship.
This relationship is kind of obscure. For plural translations, this relationship links them to their singular form. Is this worth including?
#3
I'll try to test this over the next day or so.
#4
I've tested the patch. It looks pretty good! I didn't have many problems to be honest.
A source string for translation, in English or the default site language., which doesn't make much sense in the context.I tested all the fields, arguments and filters. I haven't tested the relationship just yet.
Cheers,
Stella
#5
I tested the relationship feature and I'm not sure it totally works - however I don't think this feature is really needed for this type of data.
#6
I tried out the relationship feature as well, and also wasn't sure what to do with it. I tested also all of the fields and some of the filters and arguments with no problems.
#7
I also tried this and had very good results.
I enabled the relationship, and set it to 'require this relationship' - then I only got plural items in my view.
To me the name of the relationship is confusing
+ 'title' => t('Singular translation'),+ 'help' => t('A singular translation string that this is a plural of.'),
Since the only effect the relationship has is restricting results to plurals.
I also noticed that the fields and filters for the locales_target table are the same where the relationship is enabled or not - and that gives much more flexibility anyway. Removed the relationship, cleared the cache, and they're all still there - so I think that could simply be removed.
Otherwise great, but either the relationship needs expanding, or IMO the rest of the patch looks pretty much ready if that's taken out.
#8
I removed the relationship from this version, and tested a lot of the fields and filters, also cleaned up a few comments. Everything else seems fine to me so back to CNR.
Nearly expanded the one word field inline comments - i.e. // source - then realised they're better as they are (and consistent with similar comments in views elsewhere).
Issue attachments aren't working at the moment, so attached to my blog.
http://ca.tchpole.net/sites/ca.tchpole.net/files/views-locale.patch
#9
Apparently if you don't hit 'attach' first, attachments do work...
#10
Patch reviewed - looks good and I think it's better now that you removed the relationship - that was confusing and didn't add any great benefit. There was only one teeny tiny indentation style issue which I've included in the re-rolled patch attached.
Cheers,
Stella
#11
Committed! stella, your reroll missed locale.views.inc so I pulled that from catch's, but otherwise used yours. Seems to be ok from my end, let me know if I missed anything though.
#12
Does this fix Views not showing the localized weekday name when pulling it from a CCK field?
#13
Sorry, my mistake - looks like Date is the one to blame.
For some reason it is no longer outputting the localized weekday names.
#14
Automatically closed -- issue fixed for 2 weeks with no activity.