i18n compatibility

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

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.