I'm working on a patch to expose the locale tables to views.

CommentFileSizeAuthor
#10 views-locale.patch10.46 KBstella
#8 views-locale.patch17.47 KBcatch
#2 views-locale.patch17.82 KBnedjo
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nedjo’s picture

Issue tags: +i18n sprint
nedjo’s picture

Status: Active » Needs review
FileSize
17.82 KB

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?

catch’s picture

I'll try to test this over the next day or so.

stella’s picture

I've tested the patch. It looks pretty good! I didn't have many problems to be honest.

  • Couldn't get the 'location' argument to work. Part of this is I just don't know the format that should be entered. I know there was a translation with 'content.module:25' as the location, but the full string, 'content' and 'content.module' returned nothing when supplied as the argument.
  • The language argument - I realised that the language codes should be used, but not everyone might. Should we add that to the help text?
  • The description for the 'locale source' view type is A source string for translation, in English or the default site language., which doesn't make much sense in the context.
  • Couple of minor coding style issues in modules/locale.views.inc (coder can review patches now).

I tested all the fields, arguments and filters. I haven't tested the relationship just yet.

Cheers,
Stella

stella’s picture

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.

hailu’s picture

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.

catch’s picture

Status: Needs review » Needs work

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.

catch’s picture

Status: Needs work » Needs review
FileSize
17.47 KB

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

catch’s picture

Apparently if you don't hit 'attach' first, attachments do work...

stella’s picture

FileSize
10.46 KB

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

merlinofchaos’s picture

Status: Needs review » Fixed

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.

borfast’s picture

Does this fix Views not showing the localized weekday name when pulling it from a CCK field?

borfast’s picture

Sorry, my mistake - looks like Date is the one to blame.
For some reason it is no longer outputting the localized weekday names.

Status: Fixed » Closed (fixed)
Issue tags: -i18n sprint

Automatically closed -- issue fixed for 2 weeks with no activity.