Cannot translate metatags after last update anymore

Try the latest -dev release, I changed the context used for the translation strings.

Yeah I can confirm this as well on latest dev. Using Entity Translation with a token for dcterms.title: [node:title] | [site:name].

It will generate the token on both english + french but only the english ever shows. The functionality works as expected in metatag 1.4.

If i manually enter different text on the english + french dcterms.title that does work, just not tokens.

I am using latest dev with this issue: #2560649: Translate meta tags after tokens are replaced

Actually sorry for the noise seems the issue I mentioned above resolves my issue. I am not sure it should be opt-in behavior but it does work! Bumping down priority.

@mas0h: Can you please clarify what you're using for the translations, and presuming you're using the i18n module, the exact version you're using.

.

.

I'm going to look into this today, I'll get back to you.

Via k_zoltan on iRC: http://hojtsy.hu/blog/2011-jun-01/challenges-satisfy-translation-needs-d...

@mas0h: No, that was for my own review. I didn't get to look into this too far yet, but I'll be doing a lot of testing this coming week to make sure that the i18n integration is correct and will provide update scripts to fix existing sites.

I'm not entirely sure what changed or when it changed, and I'm not sure if I wrote a change notice for anything related either. I'm really sorry for the mess over this but I will fix it.

FYI because of a bug on d.o it's impossible to look for unpublished change notices: #2302003: Change records tabs for contrib projects link to Drupal core's change records

@mas0h: Would you please share with me an example record from the locales_source table that no longer translates? Thanks.

FYI I'm working on tests to confirm everything's where it should be, I'm hoping to have a working patch tomorrow sometime, then we can haggle on how it should work and fix the things that aren't working right.

So the problem appears to be that it runs i18n_string_translate() prior to outputting the strings, but it never announces the translations via i18n_string_update().

FYI this is related to #1986032: i18n support for Metatag submodules (Views, Context, Panels), where the i18n_string support was refactored to work better for the submodules.

I hope it isn't a silly question, but what's the benefit of using i18n_string in the first place? Wouldn't we have the same functionality just by wrapping the output in e.g. t($value, array(), array('context' => $metatag_name))? I'll be in #drupal-i18n most of the week, if anyone would be able to help work this out? Thanks.

A WIP patch I wanted to save to show some progress. Right now I'm working on making the global configurations translatable.

Further progress - the configurations are now successfully translated.

One notable change in #27 is that the configurations now include the current page's langcode as part of the cache ID.

Of course if I don't build the patch correctly it's all for naught.

This fixes the unit tests.

The i18n tests are failing because of missing test dependencies, so I've opened an issue with the testbot project (#2584815: Rebuild test dependencies for Metatag 7.x-1.x) that'll hopefully resolve this problem.

Closed two duplicates: #2030427: Integration with i18n_taxonomy for per-language defaults, #2027903: Incomplete i18n_strings integration means front page translations don't work.

Rerolled.

Closed a duplicate: #2157349: Individual front page tags

I just tested this the latest dev and the patch from #35 and the metatag strings sadly don't get translated.

They are listed on the translation interface and everything seems to be configured correctly, but they just don't get translated.

@drupov: Yes, I'm not finished fixing it yet. ;)

Closed a duplicate: #2587725: Source language of metatag strings changes to the default language of the site

Small improvements, have added another test file for just locale support.

Some fixes to the Locale tests.

Thanks for the update. Translations seem to work now, but as in #40 the source language of the metatag strings is the default language of the site and not the "Source language" definied in Multilingual settings -> Strings (mostly English).

All tests should now be green.

@drupov: I've reopened #2587725: Source language of metatag strings changes to the default language of the site after looking into it a little bit. I'm confused why it's happening this way, the labels are passed through the t() function and should just work?

#45-patch is good. Thanks!

All of the tests are passing, and the homepage translations appear to work now.

There's one test failing and I'm not sure why it fails.

Still to do:

• Make it translate default configurations provided by the hooks, right now they're not showing up on the translation page.
• Translate strings for the submodules (Context, Panels, Views).
• Translate the customized entity values.
• Fix all tests.

This fixes the broken test.

Minor adjustments.

All exported configurations are now translated too.

Fixed the tests and reordered it slightly so that now it tests for translation strings before one is manually inserted.

I split up the i18n tests into two methods - one for the default configurations, one for the custom configurations.

Some further refactoring.

The todo list:

• Make it translate default configurations provided by the hooks, right now they're not showing up on the translation page. Done.
• Translate strings for the submodules (Context, Panels, Views).
• Translate the customized entity values.
• Fix all tests. Done.

Metatag:Panels integration! Woot!

I've also refactored things a bit, including renaming the tests to be a little more consistent, and have split out the submodules' i18n tests into separate files.

Note - I haven't written any tests for the Metatag:Panels integration yet.

Based on this issue I was curious if I should hold off on updating some sites to Metatag 1.7 until 1.8 comes out. Am I correct that all metatag translations are broken in this release and this is what this issue addresses? Sorry just looking for clarification before perform some upgrades.

Based on this issue I was curious if I should hold off on updating some sites to Metatag 1.7 until 1.8 comes out. Am I correct that all metatag translations are broken in this release and this is what this issue addresses? Sorry just looking for clarification before perform some upgrades. Appreciate all the work @DamienMcKenna.

@sylus: Yes, if you're using i18n on a site with Metatag you should wait to update.

This updates the Panels integration to use the full handler name as multiple variants on the same page would have the same task & subtask strings.

Another small update, this time it only saves the meta tags if they were enabled.

This should make the i18n functionality work for Metatag:Context and Metatag:Views too. Again, no tests yet, and there are some @todo items remaining, but it appears to work. Also, no interdiff because it's getting a little complicated at this point ;-)

At this point all of the submodules have i18n functionality working, though they need tests, and the configurations (from admin/config/search/metatags) are translatable.

All that's left is dealing with the main {metatag} records for entities. The question is: how should these be handled? Any advice?

Hm, I just tested #69 with only "Metatag: Panels" and "Metatag: Views" submodules enabled and it worked for the global metatag, for a node, for a page manager page and a views page.

However I enabled "Metatag: Context" on the site also and the views page stopped translating. Also the context page did not get translated. The global metatag, the node and the page manager page still worked.

I am attaching a "drush arb" dump of the site I tested this. There is a custom module printing the content of meta name="description", so that the translations are visible better/faster.

@drupov: Is the problem you're seeing with the Metatag:Context translations happening because the per-path definitions are overriding the Views or Panels page paths that you were testing? Or are the metatag_views or metatag_panels translations in admin/config/regional/translate/translate no longer showing because the Context saved? I have all three running concurrently and I can see strings for all three, plus global configurations.

This adds tests to the Metatag:Context-i18n integration, and refactors some things accordingly.

Is the problem you're seeing with the Metatag:Context translations happening because the per-path definitions are overriding the Views or Panels page paths that you were testing?

No, I am using different paths for all configurations in this test.

Or are the metatag_views or metatag_panels translations in admin/config/regional/translate/translate no longer showing because the Context saved?

The metatag_panels translations are showing, only the views translations are not. And yes, the views translations stopped working after "Metatag: Context" got enabled. But I just tested it on a new instance (but with #73) and it worked ok.

BTW, the Context translations started translating on my previous instance (the one from #71, with the patch from #69) after applying the patch from #73. I guess it's ok now.

I hope that helps.

@drupov: Thanks, that does help.

This adds tests for the Views-based display. Woot.

Just to confirm it, the patch in #76 is for making sure that meta tags still work on pages controlled by Views.

A minor change from #76, this just reduces the amount of effort spent on cache clearing.

A minor change.

@mas0h: Thanks. Is there any way to tell what parts of the patch didn't apply correctly? In my local testing it seemed to be changes to some of the submodule info files that failed, but the main module changes should be ok.

I use the following to apply patches:
curl [URL] | patch -p1

Does phpStorm show you files ending in .rej, e.g. metatag_views.info.rej? Those would contain details of which patch chunks failed.

Applied patch from #79 against the latest dev.
There are 2 problems after:
1)In class MetatagPanelsI18nTest - 'name' repeated
2)In class MetatagCoreWithViewsTest - a)'name' repeated b)'extends' repeated

Here are my results with latest dev and patch from #79

01:14:45 /var/www$ drush dl metatag --select
Choose one of the available releases for metatag:
 [0]  :  Cancel                                                 
 [1]  :  7.x-1.x-dev  -  2015-Oct-12  -  Development            
 [2]  :  7.x-1.7      -  2015-Jul-24  -  Supported, Recommended
1
Project metatag (7.x-1.x-dev) downloaded to /var/www/metatag.                                                [success]
Project metatag contains 17 modules: metatag_google_plus, metatag_context, metatag_opengraph, metatag_verification, metatag_mobile, metatag_dc_advanced, metatag_facebook, metatag_panels, metatag_twitter_cards, metatag_importer, metatag_app_links, metatag_devel, metatag_dc, metatag_views, metatag_opengraph_products, metatag_favicons, metatag.

01:14:53 /var/www$ cd metatag/  
 
01:14:56 /var/www/metatag$ patch -p1 < /home/dimitar/Desktop/metatag-n2564483-79.patch 
patching file metatag.i18n.inc
patching file metatag.inc
patching file metatag.info
patching file metatag.module
patching file metatag_context/metatag_context.admin.inc
patching file metatag_context/metatag_context.context.inc
patching file metatag_context/metatag_context.i18n.inc
patching file metatag_context/metatag_context.i18n.test
patching file metatag_context/metatag_context.info
Hunk #1 FAILED at 2.
1 out of 1 hunk FAILED -- saving rejects to file metatag_context/metatag_context.info.rej
patching file metatag_context/metatag_context.module
patching file metatag_context/metatag_context.test
patching file metatag_panels/metatag_panels.i18n.inc
patching file metatag_panels/metatag_panels.i18n.test (copied from metatag_panels/metatag_panels.test)
patching file metatag_panels/metatag_panels.info
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- saving rejects to file metatag_panels/metatag_panels.info.rej
patching file metatag_panels/metatag_panels.module
patching file metatag_panels/metatag_panels.test
patching file metatag_views/metatag_views.i18n.inc
patching file metatag_views/metatag_views.i18n.test (renamed from tests/metatag.views.test)
patching file metatag_views/metatag_views.info
Hunk #1 FAILED at 9.
1 out of 1 hunk FAILED -- saving rejects to file metatag_views/metatag_views.info.rej
patching file metatag_views/metatag_views.module
patching file metatag_views/metatag_views.test
patching file metatag_views/metatag_views_plugin_display_extender_metatags.inc
patching file tests/metatag.helper.test
patching file tests/metatag.locale.test
patching file tests/metatag.node.test
patching file tests/metatag.term.test
patching file tests/metatag.unit.test
patching file tests/metatag.user.test
patching file tests/metatag.with_i18n.test
patching file tests/metatag.with_panels.test (renamed from tests/metatag.panels.test)
patching file tests/metatag.with_views.test (copied from tests/metatag.term.test)
patching file tests/metatag_test.metatag.inc

@chegor: What do you mean by "problems"? Do the tests fail? Do you see problems with the tests or the page output? Thanks.

@drupov: Thanks for providing that detail - the info file changes failing makes sense because the files are different between what's in git vs what's in the dev snapshots.

No, that's not about running tests.
1)Phpstorm said in these places "Patched (with problems)".
2)After patch applied in these places in code I see something like

public static function getInfo() {
    return array(
      'name' => 'Metatag core tests for terms',
      'name' => 'Metatag core tests with Views',
      'description' => 'Test Metatag integration with the Views module.',

@DamienMcKenna: yes, sorry, with the latest checkout from git the patch applies perfectly

git clone --branch 7.x-1.x http://git.drupal.org/project/metatag.git

I hope it isn't a silly question, but would anyone be upset if I were to remove all of the non-working i18n_strings -based translations of entity values (all of the values that get saved in the {metatag} table), and instead rely on the normal entity translation functionality for entities meta tags?

Just to be clear, my comment in #90 was strictly about the entity string translations, translations on config / default / Panels / Views / Context would continue to work.

The question, then, is how translations for entity values should work? Right now it runs i18n_string() on the strings before they tokens are parsed, and then again (optionally) after the tokens are parsed. Is this ok? Should it be changed to only running after the tokens are parsed? Right now this doesn't fully work anyway, so will need further work.

Current bugs:

• The i18n_string support doesn't send the strings for translation.
• The i18n_string support for output tags uses the wrong function to trigger translations.
• There isn't a separate i18n string object defined for output meta tags.
• There's practically no technical way of telling what i18n strings there could be until a page is loaded, i.e. it may not be possible to use metatag_i18n_string_list() to get them all.

The worst part? Once we work out how it should work I'm not sure there'll be an easy way to update any of the existing translations, they may have to be re-entered :( That's still to-be-confirmed, but I am concerned about it.

This updates the README.txt, removes an incorrect call to i18n_string_object_update(), and puts back in a call to i18n_string(). Output i18n still doesn't work though ;-)

Some minor improvement to the README.txt file.

Totally in favor of moving to entity translation. But I'm opinionated because we *always* use entity translation.

Functionally speaking, the big difference I can see is that i18n_strings method has one single UI for finding translations and adding them, and the entity translation way depends more on a translate dropbutton / tab / etc found on each entity being translated, thus no centralized place to enter translations and thus more clicky clicky in the UI (maybe theres a module for this?).

Aside from UX differences that are out of scope of being fixed by this issue, one addition problem that may be surmountable here is that sites currently using the string method would have to re-create translations using the entity way, so maybe the module could include an update script that checks for presence of entity_translate, and if present runs a migration inserting entities for existing strings, and removes those strings? Thinking about this again, maybe not a great method, because if the module isnt present things would simply break. Hrm... hard problem :(

Reading the last patch you're actually proposing maintaining both string and entity approaches for translation. Ok! Mindblown!

@jwilson3: Yes, we've started down the road to supporting i18n_string and sites already use it, so we can't go back. I don't think it'll take much work to do at this point, just need to confirm how it's supposed to work.

This includes i18n_strings support for output tags. And more tests.

This still needs an update script to batch-create translations for all existing sites, but otherwise I think it's functionally complete.

Please test the heck out of it :-)

Things to decide:

• For the tag output, is it ok that the meta tags are only translated *after* the tokens are replaced, i.e. it works on the final output? This means that it is no longer possible to e.g. use different tokens for different locales.
• Is the context value for meta tag output translations the way it should be done?
• Are there any problems with the current implementation, gaps in the functionality or any bugs?
• Is there anything else that can be improved?
• Besides the current plan to finish the update script to trigger the batch scanning to collect all available translation strings, is there anything else which needs an update script?
• Any other feedback?

Thanks!

@mas0h: So it seems that we need an update script to update meta tag configurations from the following structures:

lid = xxx
location = metatag:node:listing:title
textgroup = metatag
source = [node:field-listing-year] [node:field-make]  in [node:field-city] - Reference: [node:nid] |  in [variable:site_slogan]
context = node:listing:title
version = 0

to this:

lid = xxx
location = metatag:metatag_config:node:listing:title
textgroup = metatag
source = [node:field-listing-year] [node:field-make]  in [node:field-city] - Reference: [node:nid] |  in [variable:site_slogan]
context = metatag_config:node:listing:title
version = 0

I had to split out the i18n tests into separate files as it was taking too long to run the tests.

@mas0h: Can you please let me know what sort of records you see in the {locales_source} table for items that are *not* configs, i.e. that have a different format than what you posted in #18?

I've updated the issue summary with the latest details.

This adds translations to the other meta tag class types.

Don't bother trying to process meta tags on the submodules on admin pages and don't try running translations unless the 'admin page' option is enabled; making this change/fix because it was adding meta tag translations on the Metatag settings page(s).

I couldn't review as much as I liked but here's a first feedback:

For the tag output, is it ok that the meta tags are only translated *after* the tokens are replaced, i.e. it works on the final output? This means that it is no longer possible to e.g. use different tokens for different locales.

Not sure if I understand it correctly. Would this mean that e.g. This is my sentence with a [token] couldn't be switched to Yoda stylez My sentence with a [token] this is? We should be able to "move around" tokens in a translation since the structure of sentences vary from language to language.
If a token is replace before translation wouldn't this make it impossible to use tokens in the translation itself? Me is a bit confused :)

Visual code review:

1. +++ b/metatag.i18n.inc
   @@ -8,11 +8,109 @@
   +      // Table where the object is stored, to automate string lists
   ...
   +      // Table where the object is stored, to automate string lists
   
   +++ b/metatag_context/metatag_context.i18n.inc
   @@ -0,0 +1,64 @@
   +      // Table where the object is stored, to automate string lists
   
   +++ b/metatag_panels/metatag_panels.i18n.inc
   @@ -0,0 +1,64 @@
   +      // Table where the object is stored, to automate string lists
   
   +++ b/metatag_views/metatag_views.i18n.inc
   @@ -0,0 +1,64 @@
   +      // Table where the object is stored, to automate string lists
   

   Inline comments must end in full-stops, exclamation marks, or question marks.

2. +++ b/metatag.module
   @@ -2377,16 +2445,18 @@ function metatag_translate_metatags(&$metatags) {
      global $language;
   

   Variable not used.

3. +++ b/metatag_panels/metatag_panels.i18n.inc
   @@ -0,0 +1,64 @@
   +    'key' => 'did',
   +    // Placeholders for automatic paths. This connects the 'key' to strings in
   +    // the paths listed below.
   +    'placeholders' => array(
   +      '%did' => 'did',
   

   Wondering if we can / should use the uuid if available.
   A rebuild of exported displays could lead to a changed did and thus to orphaned translations.

4. +++ b/metatag_views/metatag_views.i18n.inc
   @@ -0,0 +1,64 @@
   +    'title' => t('Metatag:Views configurations'),
   +    // The object key field.
   +    'key' => 'did',
   

   Isn't this a copy/paste artifact?

@das-peter: Thanks for the review.

tl;dr: Yes, strings are translatable before the tokens are parsed.

There are three different types of string translations currently available via the patch - configurations, the submodule custom integrations (Context, Panels, Views), and then finally the output. If a site has a global configuration set up via the defaults system at admin/config/search/metatags, then those will be translated when they're loaded on the page and before the per-entity values are loaded on top; this is usually where token-based values are set, so those will be translated correctly.

The one-off values that are entered in an entity (e.g. node) form are not translated until they're output on the final page. I did it this way because I suspect that most people are not switching from one token to another on a per-node basis, that instead they're filling in complete strings, so to translate both the pre-tokenized and post-tokenized strings would result in a *lot* of duplicates.

One additional question I have: should the per-entity translations be keyed off the revision ID as well as the entity ID, or just the entity ID? Or would it be better to offer an option on which is used?

I've fixed the first two items you noticed, thanks.

As for the hook_i18n_object_info() implementations, I was kinda guessing on how to make them work, it's likely I have something incorrect.

This includes some refactoring and improvements:

• The metatag.api.php file has been reordered, slightly, and I added a few more comments.
• All hook_i18n_string_list() implementations have been moved to the corresponding i18n.inc file.
• I've restructured metatag.module slightly so all of the translation functions are at the end.
• metatag_update_translations() has been renamed to metatag_translations_update().
• metatag_translations_delete() has been added.
• i18n_string_metatag_config_delete() to delete translation strings when config objects are deleted.
• ICBW, but there may not have been anything actually triggering hook_metatag_config_delete(). This should be fixed now.

All existing questions still remain.

FYI, one thing I'm trying to do in relation to this is work out how to handle Smartling integration (#2604884: i18n_string support?), I'm hoping I won't have to change the i18n integration further because of it.

Rerolled.

Rerolled again.

GREAT job. I did test previous patches - working well

Notice: Undefined index: group in metatag_i18n_object_info() (line 99 of \sites\all\modules\metatag\metatag.i18n.inc).

and now I did test last one from #114 - all seems to be OK. You can drop 'Localized global Meta tags' module now (big thanks for author). Damien you are very active and talented maintainer - big thanks for you and rest of you who fix this.

Tested with stable version of: Domain Variable, Domain Access, i18n, variable + metatag with a patch.

Based upon experience on a large site, something needs to be refactored as the string updating via admin/config/regional/translate/i18n_string can fail on a site with lots of supported object configurations.

If anyone has any idea on how to what to do when hook_i18n_string_list times out, please let me know.

I am interested in why hook_i18n_strings_list timeouts. I don't see much difference in logic with how other modules use hook_i18n_string_list particulatly for i18n panels which has big objects to import and does roughly the same thing. Though the second link is interesting as shows how their invocation uses drupal_static before the call to ctools_include('export') and ctools_export_crud_load_all.

http://cgit.drupalcode.org/panels/tree/i18n_panels/i18n_panels.module#n302
http://cgit.drupalcode.org/panels/tree/i18n_panels/i18n_panels.module#n375

As an aside I was wondering about the following line under the hook

if ($group == 'metatag' || $group == 'all') {

Should we only need to check if the group is metatag? I guess we need to check from all the groups?

@sylus: It seems like all occurrences of hook_i18n_string_list would have the potential to time out on sites with lots of displays. On this one site I'm working with there are several hundred Panels variants spread across dozens of Panels pages.

That code is correct - when someone doesn't select a specific group to process it is supposed to process all of them by setting $group to 'all'.

FYI while I've been redoing the translation functionality to use the object system, one UX improvement I've added is 'translate' subpages for the configuration system.

Ah thanks for the clarification. I see what you mean now I wasn't able to get a time out but I also don't have several hundred panel variants. Excited to get this patch in but not really sure either how to resolve those time out issues your experiencing.

Is that the only issue holding up this release?

I unfortunately did upgrade a few sites to metatag v1.7 and don't want to resort to checking out a git hash in my makefile to apply the patch.

Though the current patch does work great and resolves my issues.

I'd be happy to help however I can :)

There are a few @todo notes in the codebase, and in my latest WIP patch, and I need to talk to someone in the #drupal-i18n IRC channel about how to implement this properly, because my current effort isn't finding the strings.

WIP to change to using hook_i18n_string_objects() instead of hook_i18n_string_list(). It also adds a new Translate page for configurations.

Todo list:

1. Finish rewriting the submodule handling to use the 'list callback' instead of hook_i18n_string_object.
2. Add translations of the {metatag} table, maybe with an on-off switch.
3. Separate the existing output translations to a new type, to avoid confusion with the table records.
4. Finish off the update scripts.
5. Any @todo items that are left.

WIP that I don't want to loose. The main configs now load metatag_i18n_list_configs, a 'list callback' instead of hooks.

Just wanted to chime in and say I really appreciate all your work on this @DamienMcKenna!

This fixes the 12 failing tests and improves the docblocks in the metatag.inc file.

patch applied partially, working good. Gonna test it in some live environment soon. Agree with @sylus.

I have tried the latest patch and all seems good as well. Still checking some integrations with tokens and panels but don't see the problems that created this issue.

Think this is the only blocker for next metatag release. I'll try to post some of the areas I tested within a few hours.

FYI the submodule configurations are being re-done.

I've applied the #134 patch to the git repo and I got pretty much everything I needed: translate strings works fine now, I could translate every meta tag, and even the multi-language front page is ok. The existent meta tags from 7x-1.7 were kept. So, thank you, Damien, a lot.

The only glitch I noticed was that if I have a [site-name] with a character that is outputted as "'" to the html source, and if I use [site-name] in a, say, og: meta tag, that tag gets to the html source as "'".

EDIT: It was the #134 patch, not #124.

@ptkobe: So it's double encoded?

Yes, exactly, I suppose.

This version finishes implementing the metatag_i18n_translate_output variable to control whether the output tags are made available for translation, and fills in the update script to convert existing meta tag translations.

This adds some initial tests for using Panels for node_view displays.

Todo list update:

• Not done yet: Finish rewriting the submodule handling to use the 'list callback' instead of hook_i18n_string_object.
• Decided not to do this: Add translations of the {metatag} table, maybe with an on-off switch.
• Done: Separate the existing output translations to a new type, to avoid confusion with the table records.
• Done: Finish off the update scripts.
• Not done yet: Any @todo items that are left.

@ptkobe: Ok, I can confirm that. Bother. Guess I'll have to fix it ;)

Ok, the double-encoding bug is being handled in #2180031: Metatag displays "'" instead of apostrophe in meta title tag.

I've fixed the double-encoding bug in #2180031, now back to the main event.

Applied metatag-n2180031-14.patch and it solved the double encoding on #134.

I guess I should say that I'm testing only for meta tags on pages with multi-lingual support (not for panels or views, context, admin pages, etc...).

patch at https://www.drupal.org/files/issues/metatag-n2180031-14.patch

We started using the Metatags module on a multilingual project more extensively just recently. Nodes are being content translated using i18n 7.x-1.13.

This seems to work just fine for nodes and views pages, but not for the front page node which always shows the metatag texts like title and description in the default language. NB: It only happens when the path only exists out of the language prefix as in /nl, not when the path is the full alias to the translated front page node as in /nl/my-front-page.

I tried the dev version if Metatags patched with patch from #142, ran database updates and cleared all caches, unfortunately no changes.

Is what we are experiencing related to this issue? Thanks a lot for all the great work!

@lmeurs: Please describe how your front page nodes are set up - are you using Entity Translation or Content Translation, are you using the same nid for each version of the front page or do they have different nids, are you using the "front page" configuration from admin/config/search/metatag or the node's values?

@DamienMcKenna: Thanks for the quick response! The culprit appeared to be the same node ID for both languages. Since the front page only shows blocks and no node content we did not notice this any earlier... After changing the settings everything worked out fine with the latest stable version of Metatags. My apologies for the noise and so many thanks.

@lmeurs: No problem, thanks for chiming in.

We are using Panels Everywhere and have encountered a serious issue with using current_path() in the string context.

As Panels handle all the page views on the site a new string context is created for every unique url on the site.
This has led the translation table to grow out of control to 1 million+ rows.

We have a lot of entities passing through the site every day so we have a lot of unique urls that only last for a short time before being replaced by others.

function metatag_translate_metatag($string, $tag_name, $context = 'metatag', $langcode = NULL, $update = TRUE) {
-
-
-
-
  if (is_array($context)) {
      $new_context = 'metatag:';
      if (drupal_is_front_page()) {
        $new_context .= 'frontpage';
      }
      // If this is an entity page, use the entity as the context.
      elseif (!empty($context['entity_type']) && !empty($context['entity'])) {
        list($entity_id, $revision_id, $bundle) = entity_extract_ids($context['entity_type'], $context['entity']);
        $new_context .= $context['entity_type'] . ':' . $entity_id . ':' . $revision_id;
      }
      // Otherwise, use the page URL.
       else {
         $new_context .= 'page:' . current_path();
      }

      $context = $new_context;
    }
-
-
-
}

@rodarc: That's an interesting issue. For your scenario, what would you suggest doing here? Maybe add a hook for custom modules to work out a context to use?

Thanks for your quick reply.

I think that a hook would be a good solution.

This adds hook_metatag_i18n_context_alter() which lets the string's $context be altered before it's passed in, and if the string is erased then it won't be translated.

Still needs work on the submodules.

This is a WIP to rewrite the submodule handling using the new list/load structure. It doesn't work yet and I'm starting to get concerned it might not work due to the use of CTools exportables.

@webflo: How would you suggest handling the submodules? They all have the situation where they need to identify configs that are both exported and in the database, so the primary 'key' value wouldn't always be applicable? I've added both a 'list callback' and 'load callback', but it doesn't seem like the load callbacks are being triggered? Any suggestions? Thanks.

FYI the question in #58 is open to anyone who might have an answer, not just webflo :)

Renamed the MetatagCoreWithI18nTest class to MetatagCoreWithI18nOutputTest, and other minuscule changes.

Forgot to update the info file.

This adds assertResponse() calls for all drupalGet() and drupalPost() calls.