Translatable meta tags content

It is only possible for node keywords because if you have i18n module each node will have translation nodes and every node may have its own set of meta tags.

You can also keep translated global meta tags because they are stored in a variable which is translatable by i18n module.

But! There is a huge problem with front page meta tags - they are stored in nodewords table directly (type = page and id = NULL) and can't be translated. So, you can't have multiple sets of front page meta tags per each language of your site.

I'm about to propose a patch for this...

Quite important feature for a multi lingual website. If there is anyone willing to sponsor this, I'd be glad to implement this feature.

We need this as well, has there been done any work on this issue yet?

subscribe

subscribing.

subscribe.

This problem renders this module quite useless (for anyone who's running an multilingual website).

It's idea is SEO - but having the wrong set of keywords is far from good SEO...

@toemaz: If you could check out what needs to be done and how much work that will take, please let me know. we may be able to help.

If anyone has any other ideas - i'm all ears!

Thanks!

@asak

Sorry, don't have the time anymore to improve the module. But I agree, for a multi lingual website, this module is rather useless.

The Assigned field is thought for the maintainers of the project.

I found that using multilingual nodes/views for frontpages, which means using a specific node/view for every language as front page with its own set of meta tags, solves the front page meta tags problem.

It would be great if someone found a way to deal with multilingual setups. As noticed above, nodes aren't the problem, each translation is it's own node after all. I would like to be able to store the Views description and keywords variable in different languages.
A trick that has worked before with other contrib modules lacking language support is adding the variables in your settings.php, like

$conf['i18n_variables'] = array(
  'nodewords_view_description',
);

Except that I can't find a variable we would need. Are the metatags stored in a variable so we can do this trick?

"Are the metatags stored in a variable so we can do this trick?"

No they aren't, at least not all nodewords variables are stored in the typical Drupal variables. So the only solution I see is to rewrite the module and move all variables under nodewords_settings() function which implements the good Drupal way to store variables.

subscribe

This patch enables to customize keywords and descriptions for the front page for all enabled languages. It modifies the admin/content/nodewords/frontpage page, and adds a section for each language.

It adds a language field to the nodewords table and the primary key, so multiple instances are allowed to exist.

I've only tested it on a multilanguage installation (with per domain language setting), so I'm not sure if it might break an existing configuration, but the module maintainer should be able to review this...

NB! don't use these, please use the patches further down on this page...

Should you extend the update function to set the language for the already existing rows?
This doesn't actually change what meta tags content is shown... it only works for frontpage, right?

I'll have to look at it a bit more carefully, but this is already a step towards i18n. After I've looked at it a bit closer and/or someone else comments, this may get into nodewords quite soon.

Updating existing rows is probably a good idea, yes. I'll add it to the list.

It is only implemented for the front page but I guess it be prepared to work for anything that uses this table (I only have page records in the table, so I haven't had the chance to test anything else). On a norwegian site it shows the norwegian keywords and description on the frontpage, and likewise for any other languages that may be installed.

(and this patch really has nothing to do with i18n, it's just relying on the locale module)

New patch, in addition to what was mentioned above;

• Now localized taxonomy terms and descriptions are translated (i18ntaxonomy).
• Existing rows are copied to all enabled languages for the type 'page' on install

Patch is for current 6.x-1.0 release.

Any chance for a D5 backport?

Here's a patch for the keywords.inc file to properly translate the taxonomy terms added as meta keywords to nodes...

And here's the patch for description.inc...

Great that you are working on this, SeroSero. Hope to try these patches later!

Expect a rewrite - I think we're better of doing what toemaz suggested; use the builtin support for translation of system variables. The variable translation system is terrible, because you have to edit settings.php to make it work - but on the other hand translations will be stored in a standardized and pretty robust fashion. I'm using the current patch on a production server, but doing the rewrite of how variables are stored is pretty high up on the list, as it would solve translation of the global keywords as well.

+1

SeroSero: did you get to it? are you still using the patches you provided on production sites?

Hi,

When do you plan a dev version with i18n patches to help many of us test it ?

Thank you.

I'm very interested in this. I might consider a sponsorship.

subscribing

As i18n.module is not a core module, I think this code is more suitable for a separated module.
After the module API will be stable, we can think of creating such module.

EDIT: The module can be part of meta tags, or be a project apart.

Patches should be applied to the development snapshot, not to official releases.
An official release already existing cannot be changed, if not creating another official release that is created from the development snapshot.

As the patch uses functions present in a third-party module, I still think it doesn't fit in nodewords.module, but it should rather be part of another module.

subscribing

It would be a great improvement to be able to translate all meta tags.

For nodes keywords there is already a solution by using taxonomy "Auto-keywords vocabularies".
Keywords included as such are correctly translated.

After applying pacthes on #17: admin: node settings displayed in both "settings and filters" an, descriptions and keywords are not loaded on node pages.
So here is a fixed patch I provide that seems to correct this bug. I just add a the function _nodewords_language() call before the update queries if the language code is empty. This forces the language code to be saved properly in the table for nodes.
Edit: This is an erronous file so don't use this.

Ok. If your descriptions and keywords are not loaded on node pages. Here's the fix. I just added the function call _nodeword_language() before update and delete. So it forces the language code when it's empty.

@#32: Patches needs to be against the development snapshot.

subscribe.

subscribe

See my comment #33.

@KiamLaLuno: can you help by making the dev version available on the project page?

The development snapshot is now visible on project page.

Thanks. In the mean time I did find and download it from cvs and tried to apply the patch manually, but it's much more tricky then I expected. So unfortunately I won't be the one to make it happen.

btw from another post I can see that you would like many people to test the dev version - I think you might have a higher testing coverage when the dev version is visible on the project page, so I would leave it visible.

The patch for version 6.x-1.0 doesn't apply to the development snapshot; that is the reason this report is marked as needs work.

Does anybody know if it is possible to use the patches available here on the recently released 6.x-1.2 version of Nodewords?

I think it should be a separate module, there are a lot of non coders, waiting for this fix, without the need of patching or using a dev version this is a most feature for SEO purpose, hope someday I can see this module or a similar one. , it would be a helpful module.

comment #32;
I guess in the patch, line +439,18 it must be
return db_query("DELETE FROM {nodewords} WHERE type = '%s' AND id = '%s' AND language = '%s'", $type, $id, $language_code);

instead of;
return db_query("DELETE FROM {nodewords} WHERE type = '%s' AND id = '%s' AND language_code = '%s'", $type, $id, $language_code);

I subscribe

About the translation of meta tags using i18n variable system, I think this is not possible.

The informations are not stored in the variable table, but in a custom nodeword table, so i18n is not designed for that.

There are 2 solutions :

- Register nodewords default setting as a drupal variable, so, i18n should be able to translate them. For the node level meta, they already are translatable because each translation is considered as a new node.
- Implements a custom multilanguage system in nodewords, which is certainly more complex but can bring a far better UI.

But yes, this is a very important issue, I'm surprised to see it now whereas multilanguage was a Drupal 6 credo since the begining.

I have marked #611666: Multi Language - Site Information as duplicate of this report.

subscribing

subscribing

subscribing

Recent development snapshots introduced the field language, and changed the unique key to include that field.

Now, the only change that must be done is the code. In the case of nodes, that is easy (it's enough to consider the language associated with the node); for the other cases, I am not sure what should be done.

For the fields added in taxonomy terms edit form, it seems that adding a selector for the language could be a solution; when editing the meta tags for a taxonomy term, I would first select the language for which I would change the meta tags, and then change the meta tags (the form would be only one).
The same is true for the edit form that allow to set the meta tags for the front page, the error pages, ...

As this feature requires an API change, it will be implemented in branch 6.x-3.

And what about the fact that is no possible to use "Other Pages" in Nodewords to create different Meta Tags per language, with the path matching?
For example if you set in "Other Pages" different meta tags for a specific path "us/*" only the default meta tags are displayed.

For example if you set in "Other Pages" different meta tags for a specific path "us/*" only the default meta tags are displayed.

The language prefix is not passed into $_GET['q']. The only way to detect the language set is to check the content of the global variable $language.

Hi,

Great module, I especially like how you can define meta tags for a view, by entering its path.
But like you say, it doesn't work for multilingual paths, yet.

Do you think this feature will be implemented in a future release?

Thanks.

subscribe

Is there any module to make frontpage of multilingual Drupal website search engine friendly?

Why did not drupal solve this problem after so long time?

subscribing

Netrunner: It is possible to make the frontpages of multilingual Drupal website search engine friendly, just follow the directions given here:
http://drupal-translation.com/content/setting-front-page-language

We took a different approach, which works for our needs.

We patched nodewords.module to run the tags through the 't' function:

function nodewords_load_tags($type = 'default', $id = '') {
  $result = db_query("SELECT * FROM {nodewords} WHERE type = '%s' AND id = '%s'", $type, $id);
  $tags = array();
  $tags_info = nodewords_get_possible_tags();

  while ($row = db_fetch_object($result)) {
    if (isset($tags_info[$row->name])) {
      $tags[$row->name] = $tags_info[$row->name]['tag:db:type'] != 'string' ? unserialize($row->content) : array('value' => t($row->content)); // translate content
    }
  }
  
  if (empty($tags) && $type == 'term') {
    return nodewords_load_tags('vocabulary', db_result(db_query('SELECT vid FROM {term_data} WHERE tid = %d', $id)));
  }

  return $tags;
}

Then, we used the locale module to import .po files containing the translation for the keywords, description, etc.

This way, change is minimal and it uses the core locale module to manage the translation.

I have taken another approach and gone the block views route, abandoning page views and their paths, which were quite a hassle in the first place.

In stead I will simply make ordinary pages with a block added in the content area. When a page is translated from the English version to another language, the new path is added to the block, to also display the block on that page.

Granted, there is a little work involved, but I now don't have to set URL aliases, and I can have meta tags for all languages.

It also makes it easier for the editor, since everything now is pages, in stead of a mixture of normal pages and page views, which have to be translated differently.

I will also have to define less custom_breadcrumbs, since large parts of the paths are now ordinary menu paths, and can be generated with menu_breadcrumb.

We took a different approach, which works for our needs.

We patched nodewords.module to run the tags through the 't' function

As reported by the documentation of t(), the first argument must be a literal string, not a dynamic value.
Then t() is being called too early, as it is not still defined which language to use; if the meta tags are shown in a node that has Chinese as associated language, you cannot use the default language, as this would lead you to have meta tags in English (in the case the default language has not been changed), or French (if the default language has been changed) in a node that is written in Chinese.

Hello, will be this important feature in the 6.x-3.x version? And, if affermative, when will be it released, about.. ? I need it very bad. Thanks in advance for your exceptional work.

Yes, it will be. I cannot say when it will be implemented, as there are some details I need to verify.
The fact I am the only one to develop code slows the development of the module, then.

Hello,

I did a similar thing as ronn abueg in #58 so my meta keywords and description would be translatable. In nodewords.module, function nodewords_output_tags:

      if ($bool) {
        $template = $tags_info[$parts[0]]['tag:template'][$parts[1]];
        $replace = array(
          '%name' => $meta_name,
          '%content' => ($template == NODEWORDS_META) ? t($meta_content) : $meta_content,
          '%attributes' => empty($tags_info[$parts[0]]['tag:attributes'][$parts[1]]) ? '' : drupal_attributes($tags_info[$parts[0]]['tag:attributes'][$parts[1]]),
        );
        $weight = isset($tags_info[$parts[0]]['tag:weight'][$parts[1]]) ? $tags_info[$parts[0]]['tag:weight'][$parts[1]] : 0;

I changed the order of the lines (put $template definition first) and then depending on $template I make $meta_content translatable or not.
So now my meta tags output in the current language :)

@saipas: The first argument of t() needs to be a literal string. If to get translatable meta tags should be enough to do that, then I would have done it already. ;-)

Subscribe

I've got different nodes as setup as frontpage in settings -> site information using multilanguage variables (in settings.php -> i18n_variables).

The nodes themselves have meta descriptions but they don't show up on the frontpage.
I expected this to work as a workaround for this issue. But it doesn't.

@kiamlaluno: yes I encountered that issue in other modules, strangely in that one no error arises. Anyhow, the workaround is to use the following:

$tr = 't';
$meta_content = $tr(meta_content);

@saipas: Your work-around doesn't work either. The script that is used to extract the strings to translate looks for code such as t('literal string'), and it is not able to handle $tr($meta_content) because it cannot know the content of the variable $tr, and see if its content is the string 't' (in the same way it is not able to know the content of the variable $meta_content, which could vary at each execution step, and not be a static value).

Your workaround works only in the case the script already found another code line that passes that string to the function t(); if you are using a string that is not used from other modules (such as the case of the meta tags content — I don't think a module uses the same string you use for the meta tag content in its user interface), then the string is not added from the script to any translation template, and nobody will translate that string.

I am changing the status of this feature report, as at the actual state is postponed.

subscribing

Subscribing

subscribing

Joining in with the feature request. I understand the possibilities to use specific tags as per page, but for Custom pages meta tags (e.g. Views-related), unfortunately, this is not the case.

What is the best version of nodewords to use on production website with multilanguages ?
What is possible to do with it ?

Regards

Using the $conf['i18n_variables'] on Settings page's fields is working (like 'nodewords_global_keywords'). I think the problem on Default and specific metatags page's fields is the same fieldname for every subpage (Front page, default, 404, 403, etc), so on this pages the i18n_variables doesn't work.

Patch for nodewords taxonomy translation, works for me

works great. Hope that it will be comitted soon :-)

Is possible commit the patch????

Is this patch to translate Taxonomy terms in MetaTags ??
I don't understand what it adds.

Since long time terms are translated in MetaTags.
See my comment in this same issue : http://drupal.org/node/130389#comment-1929164

Implementation of Taxonomy Terms in MetaTags have changed. They now used Token.
I supposed maybe this new implementation doesn't translate them anymore. But it does.

I use nodewords 6.x-1.x-dev without patch and Taxonomy Terms are translated.

Could you precise what this patch brings ?

EDIT : Status was updated since I was written my comment. Sorry to revert status change, it's not my fault.

@kiam

Sorry!!! in this comment I update the version for the patch to 6.x-1.11, because this patch is for 6.x-1.11 version

@srobert72
Mi site have to languages English and Spanish
I´m using the option "Auto-keywords vocabularies:" and when I visit a node in both languages the META "title" is in english, this patch solves this problem translating the term to the desired language.

Sorry for my (very) bad english i hope this post will be understandable

@lord_of_freaks
Title is HTML tag not a Meta tag.
Or do you want to say "Dublin Core title" which is a Meta tag.

I also have a site in English and French.
Without any patch :
* Title tag (<title>) is well translated
* Taxonomy terms (<meta name="keywords">)are well translated
* I don't use "Dublin Core title" Meta tag so I can't say for it

I think there was confusion between words (term, meta, tag) which were not always used properly in right place.

@srobert72

Sorry I said "title" the right META is "Keywords"

Perhaps Ubercart module breaks translation without this patch ... i don´t know ... the vocabalary "Catalog" is not translated into Keywords metatag using nodewords-6.x-1.11 (last recommended realease)

Thanks anyway

i18n compatibility will be implemented in branch 6.x-3.

Can i get current status of node words and multi language issues? Is it possible to use it for multi-lang or is it useless for that task?

I do not believe the current v6.x-1.x codebase provides any direct support for translation, but please check hook_nodewords_tags_alter() and hook_nodewords_tags_output_alter() in nodewords.api.php for hooks which should accomplish what you are looking for.

I marked #951802: Make default meta description/tags translateable as a duplicate of this.

Reopening this, re-assigning it to the v6.x-1.x branch, and I added a note to the module's project page explaining the current internationalization support.

Thanx Damien, will look at this.

Resetting the issue settings.

Hi everyone.
@DamianMcKenna or Dave Reid,
Can you provide some further direction on how to properly get meta tags (main description and keywords translated ) translated.

From what I understand we can use one of the hooks the module provides? How?

I tried this in a custom module but ended up with doubled keywords and description

function mymodule_nodewords_tags_alter(&$output, $parameters){  
    if(drupal_is_front_page()){       
        $output[description] = t('blah blah blah');
    } 
}

Is this the wrong way to do it?
Would you suggest upgrading to 3.x dev?

Can someone suggest a workaround that is production safe? (Obviously to the best of their knowledge without any guarantees)

With over 70,000 known installs there must be people who have gotten their keywords to translate.

I understand that the module was designed for nodes, and is know being pushed into other entities (pages and things that aren't nodes) but it is the definitive module to take care of key words

I'm including a list of other threads in the issue queue, maybe one them is relevant.

#951802: Make default meta description/tags translateable - Dead end

#770440: Create a module that allows to translate meta tags - Never done. Thread not closed.

#810322: Language support for nodewords_custom_pages - Patch ignored

#913108: Multilingual translated front page meta tags - Newer thread with similar issue.

#917190: Nodewords on mulit-lingual sites - 3.x feature request should we close this issue and move discussion over there?

I know, it's only a workaround but, in the meanwhile, it works:

Insert the following code in settings.php:

$conf['i18n_variables'] = array(
  // Different front page for each language
  'site_frontpage',
);

Then set a node/x in the "Dafault front page" textfield on admin/settings/site-information for each used language,
last uncheck "Use front page meta tags" option from the page admin/content/nodewords,

et voilà it works, and you can set your meta like you normally do for internal pages.

Thanks tourtools,
but what if i don't have a node set to be home, but a panel?

sorry, but if you are choosing the language for your content inside the panel via views, there no way than waiting for a code solution, but you can choose another way to do this setting a node without body and hiding the node title in some way and displaing your panel content in another way, I don't know very well panels, so I can't suggest the best solution, maybe trying to display a certain language panel using multilanguage blocks or contexts can do the trick joined to the #97 solution.

But maybe you can achieve this showing your panel on node/xxen node/xxit node/xxde, and like I said hiding the node and obtaining to publish metas.

Closed #1049778: Translate meta tags as a duplicate of this ticket.

Closed #917190: Nodewords on mulit-lingual sites as a duplicate of this ticket.

Closed #913108: Multilingual translated front page meta tags as a duplicate.

Closed #770440: Create a module that allows to translate meta tags as a duplicate.

subscribing...

Subscribing.

I've developed a module to add multi-languages in the nodewords settings for frontpage, 404, etc. Currently it's a sandbox project here:
http://drupal.org/sandbox/jyee/1103360 http://drupal.org/project/nodewords_translate

At some point, I may decide to upgrade it to a full project, but I thought I'd get feedback for a while before launching that.

The basic idea is that it duplicates the existing nodewords form fields for each language enabled on your site.
Those values get stored into a separate table called "nodewords_translate"
Then it calls hook_nodewords_tags_output_alter() to retrieve any translated meta information and output new metatags.

I don't have a lot of time to maintain this, so if you find any problems, submitting patches is appreciated. Also, if any of the nodewords maintainers have insights on better ways to leverage nodeword's hooks, I'd appreciate those as well.

#106 -> Page not found

Can I download this anywhere ?

Perfect timing! Of course the only time anyone goes to find the module is right after I decide to promote it to a full project! :D

That module is now available here:
http://drupal.org/project/nodewords_translate

This is great news! I managed to translate my keywords and description tags using standard translation interface in drupal after adding this line in nodewords.module:
if(strlen($tags[$row->name]['value']) > 0) $tags[$row->name]['value'] = t($tags[$row->name]['value']);
right after:
$tags[$row->name] = unserialize($row->content);
in nodewords_load_tags function.

But now I'm going to try your new module out.

Hi May be all translate stuff, like other/custom pages meta tags should be focussed in this new module nodewords_translate: http://drupal.org/project/nodewords_translate?
greetings, Martijn

Hi. I'm running a multilingual website win 5 languages. There are several pages generated by panels that were used to present info in all the 5 languages. The problem is that we can not assign different meta tags to the same panel page for the different languages, even if we define custom pages as "en/panels_page" and for french "fr/panels_page".

Can anyone point us a direction?

Thanks. Best regards

Edu

What is the right solution for this problem? This thread started in 2007 and there still seems to be no clear correct thing to do.

I am using 6.x-1.x-dev. is the option in #97 best or the new module: nodewords_translate

What is the best solution for multilingual home page keywords and description in August 2011?

@martijn: thanks for sharing, sometimes I miss the obvious.
This module is a step towards a solution, but doesn't address the whole issue.
The real problem is that t() parsing dynamic strings ($variables) is a "no go" in proper Drupal development.
If this is no option there is no alternative than to "form_alter-ing" an extra field for every possible node_words field available per language, and handle that properly when loading your node/panel/taxonomy/commerce/views/whatever page there is that contains these.

I think this should be addressed at the root of the problem, the node_words module. But easier said than done though...

Regards

Beddengoed jongens meisjes

Making these easier to index.

When we were to solve this problem on a multilingual site, we simply used the hook_nodewords_tags_alter to add the t()-function to the tags.
Not entirely sure whether it's the most clean way to achieve it, but it works well enough.

Unfortunately this module is no longer supported, so I'm closing this issue.