Multi-language patterns for single Content Types

Currently you cant specify different Page Title patterns for different languages on the same node type. This is a good point though...

Marking as a Feature Request.

Nick

Excellent - thanks Will. I'll try to get this converted into a patch and committed for a future release.

willeaton
I did not understand the solution you have provided (perhaps a patch would be helpful)

Here is what jose reyero seems to be proposing in order to make i18n_variables for ANY module
http://drupal.org/node/252245#comment-1194143

I suppose if system_settings_form is used in the module and appropriate variables are put in settings.php in i18n_variables

$conf['i18n_variables'] = array(
  'site_name',
  'site_slogan',
  'site_mission',
  'site_footer',
  'anonymous',
  'menu_primary_menu',
  'menu_secondary_menu',
  'contact_form_information',
  'site_frontpage',
//following we are internationalizing the module's variables
  'page_title_front',  
  'page_title_type_content_type_name',
  'page_title_type_page',
  'page_title_type_story'
);

then each variable will be internationalized

I don't know how to code such solution but just throwing it out there for anyone that is more advanced with drupal internals

I just installed the AWS version and it doesn't have a frontpage option for the other languages. I have sites with multiple subdomains like

www.domain.com
es.domain.com
fr.domain.com

Is there a way to add a slot so each languages homepage has it's own title? I'm not using the sitename as the title tag.

The PAGE_TITLE module can use the VOCAB translations of i18n module (Taxonomy Translation)?
By example, I have this pattern:
[site-name] > [vocab] > [page-title]
I could have this titles:
Drupal.org > Essential Modules > My Module
Drupal.org > Módulos Esenciales > Mi Módulo

In this case "Módulos Esenciales" is translation for vocab "Essential Modules", how to enable this feature?

Has this feature been added to a development snapshot? Is there a patch that applies with the most recent stable release?

Sorry, posted a new request and this one already existed. Please check http://drupal.org/node/706410

I copy then my suggestions from the other post that was marked as duplicate.

Drupal supports translation of nodes. It's very usual to have multilingual websites based on drupal and in fact there are a lot of them. This module is highly adequate (in fact this functionality should already be in drupal core) but in any case, you should offer the possibility of wording page titles differently depending on the language of the node. Pathauto already offers this by multiplying fields per language:

Pattern for all language neutral user paths:
Pattern for all user paths in English:
Pattern for all user paths in Spanish:

Page titles shouldn't be that different. Don't you think such a solution would be simple and adequate?

Hmm is this really that complicated? Did someone read my reply? If pathauto is capable of doing this, I am sure pagetitle has an easier task!

Hey, I have found that multilingual patterns are already working! No need to patch any module. Just try solution #6 by GiorgosK in this same thread. You need to install i18n and add the variables yo want (just open your database with phpmyadmin, go to variables table and check those starting with pagetitle). Then you must run cron, and edit multilingual variables as per i18n rules!

You don't even need to jump in your database
but the i18n_variables is a workaround so please keep this issue open
and let the maintainer decide if it will be implemented

How could we find i18n_variables for other page like vocabularies ?

Found it:
replace XXX by id of the vocab

page_title_vocab_XXX

Great discussion indeed!

It is true that multilingual support of Page Title would be necessary for SEO purposes and a good users experience.

I love the idea of the principle of Will Eaton's work (unfortunately it did not worked for me!).

For good SEO with multilingual web sites, it would be great to be able to list for each language the appropriate fields and assign them different patterns, not just translation thru the fantastic i18n module. The way people browse the web in different countries is not the same in terms of keywords used to be in a good position on ranking results... It often depends also on the local competition due to some keywords... And a great localized title is better than just a weird result of a translation thru i18n...

I noticed one stranged behaviour in Page Title... For the need of good title in several languages and for SEO purpose, I defined default patterns for some content types in one language, and in order to get another pattern in another language, I have decided to show the title field for such content and give it another pattern while I am editing the node in the other language... One problem here: once done, the title for the second language displays both the overriden pattern and after the default pattern of the first language! Is this a normal behaviour of the Page Title Module? I thought that you could override the default pattern and not just add it to a specific one...

In Drupal 5, I used Title Rewrite to make the trick for the different languages thru path handling... Unfortunately, this module has not been ported to Drupal 6 even if we have heard ideas of merging it with Page Title...

Page Title is trully a fantastic module with great code and so easy to use for such purpose.
Why not merging efforts for making it working as expected in multilingual schemas as exposed, not only via i18n translations... So Nick, what would be the directions taken for this feature in the next weeks?

Best regards,

Chrys

Hello,

I attached a patch to solve a part of the problem mentioned by this thread by allowing patterns by content types and languages in an interface similar to pathauto

This patch do the following :
- add page title patterns for content types by enabled languages.
- add a default pattern for each content type that will be used if no pattern is set for a precise language.
- the patch only provides page title patterns by languages for content types atm, that's why i put the status "needs work"

It doesn't really change the way the module is working, it adds variables in the variable table in the form of 'page_title_[content_type]_[language]' and code to retrieve them after that. I also added a submit handler so that the related variables are deleted after a language is deleted.

I've tested it on both a dev version of a live website with 3 languages and a test website, and it seems to behave correctly. Still it needs further testing, i guess.
We also need to determine if the approach is right. If it is, i'll go on and provide more versions of this patch if required.

PS : this is my first patch, so it might not be created the right way, i git diff against the latest dev in the page_title module folder.

Subscribing

I need a different page title to be used depending on the language prefix of the node.

www.example.com/page-title-in-french
www.example.com/en/page-title-in-english

I don't have the content type to be multilingual with i18n module but rather just added new fields with _en appended for the English translations and output the fields depending on the $language of the page being viewed.

Can anyone please point me in the right direction or what to test to achieve my goal?

Thanks!

@hles - that patch looks like a GREAT start, thank you! I'm not an expert at multilingual sites - can taxonomy terms be translated too, or just nodes?

WARNING: approach in #6 does not work with latest dev (don't really know why)
tested it with working 2.3 version then updated to dev and stopped working (cleared caches and all)

#21 patch looks good so far
- still needs implementation of the localized page titles
- localized category titles if possible

had to erase contrib/ and a/ and b/ from the paths inside before I could make it apply
(uploading the result for anyone having same issues) otherwise its exactly the patch from #21

Could someone kindly explain what the process will be (screenshots super helpful!) in setting the page title per language if I had the below setup on my site.

www.example.com/ << French
www.example.com/en << English

Changing status to "needs review"

@nicholasThompson #23
I didn't really take a look at the rest, as i didn't need it right now. Atm it just works for the different content types, but i think it should be straightforward to complete all the other cases.

@GiorgosK #24
Thank you for the path modifications.
What do you mean by "localized page titles" ? Because actually, that's what the path does, providing localized page titles for each content types.

@yaz085 #25
Page titles can be set independently from your path settings. You can set default page titles in function of the language. The showfield option (checkbox) allows you to override the default titles by providing an input in the node edit form itself. I attached a screenshot (just an example), maybe it helps.

The patch solves the Content Type problem which is the title of the issue but maybe we should keep the status to "need work" until all the other cases (Frontpage, Vocabularies etc) are implemented and change the title instead ?

I think i can take a look at the rest in the next few days.

@hles
I was just referring to the non functioning of your patch
it asks for the different patterns per language but it does not do anything with them yet (or did I miss something ?)

Ah well, this patch was against a previous dev version which has been updated now. Maybe that's the problem.
But this is exactly what provides the patch when it works.

I spent some more time working on that patch. This is a patch against 6.x-2.x-dev of 2010-Oct-27.

This version should do the following:
- Add localization for all page title patterns that are existing on current versions (for enabled languages only).
- Add fallback patterns for content types to deal with content with no language.
- A slightly modified version of the administration page to handle more clearly the page titles because the number of rows in the table was becoming huge with more languages activated. Important patterns are displayed directly at the top, whereas other categories of patterns are displayed in fieldsets just after. (see attached screenshots)
- Remove all variables from a language when deleted, keep them when disabled.

Other:
- Are vocabularies really handled the right way ? Maybe i'm missing something, but we give a way to provide title patterns for them on the administration page, and then we test them against the url ( ?q=taxonomy/term/11 ) except 11 is an id for a term (nid) and not an id for a vocabulary ( vid ).
- The patch doesn't provide a way to migrate page titles patterns from other versions to the patched version.

Testing :
I tested quite almost everything, but not vocabularies and not views at all. I feel that the behavior is correct but i really think this should be tested by more people because it's hard to test all configurations possible.
Note that this patch doesn't use exactly the same variables that were displayed previously, so you won't see all of your old patterns after applying the patch. But you could still use it to define your old patterns again, it would work. So please, test it on a dev environment.
I also attached a zip of the patched version of the module, so you don't have to patch your current version for testing.

@hles
thanks for the effort you are putting into this and I will be around to test any other progress that you make

Tested a content type with two languages and term pages with two languages

still some things are not quite there
1. categories are presented with textbox for patterns but pattern used does not affect the "taxonomy term page title" at all (study how the original module does it because its working but not for localized terms)

2. categories is missing an "independent" textbox for pattern (for fallback) or is there not needed ?

3. A suggestion:
I would eliminate the "help/descriptions" under under each and every textbox since most of them describe the same thing and occupy 1-2 extra lines unnecessarily IMHO. (i.e. "pattern used for frontpage", "pattern used for fallback all page pages" etc)

I would make a generic description on top of each fieldset for help purposes (i.e. "per language patterns are used for calculating page titles per content type. The independent field is for fallback on content that has not been assigned a language")

On sites with many content types and vocabularies even each collapsible fieldset becomes quite long and several moves of scrollbar down

@Giorgosk
Thank you for the review and tests.
I took a look and changed a few things according to what you said. In fact i wasn't sure we needed fallbacks for everything, but i decided to add them all finally. About the descriptions and the interface in general, i agree with you, but maybe we can do that in another patch so we can focus on localization right now. Maybe the maintainer wants to tell us how he sees it in this thread.

Since last patch:
- All fallback patterns added.
- Added support for vocabularies.
- Added cleaning of variables related to a vocabulary when it is deleted.
- Some bug fixes.

The patch should now work for everything (i hope). It is against latest (new) dev.

Something was wrong with the vocabularies' variables deletion.

when going to "taxonomy patterns"
I get "No pattern possible" in the independent textboxes
and when I use the language boxes they are not applied to the "term page"
(they are not affecting the page title at all)
Am I missing something ?

Ok - a 46Kb patch is big! (for this project anyway).

I'm gonna hold this one back for the 2.5 release as I REALLY wanna get 2.4 our the door. A lot has changed with the module's API recently, so I'd like to get a tagged release for people to start working against, rather than this moving goalpost which is -dev ;)

Awesome work though guys. I'm not so hot on the i18n/localization stuff (can just about manage English!) so am very glad for the help here.

@GiorgosK
Your are right, the "No pattern possible" shouldn't be here, it's a default value i used for dev and forgot to remove. You can change it though. I found out that the taxonomy patterns applied via the page-title administration page work but not the ones that are set in a term page via showfield (if it is what you meant). I'll fix that when i have some more time.

@nicholasThompson
I think it's better that you get the 2.4 released first if the API has changed. Actually there are no new mechanisms in the patch, it's just dealing with ore datas) but i'd rather work with a final version of the API. This patch does enough for me right now anyway.
Btw when you talk about a stable 2.4 version, it's about D7 or D6 or both ?

@hles
the patch needs to modify the page title displayed on
language/taxonomy/term/xx
for the vocabulary/language the user has give a pattern for

@GiorgosK
Do you mean that default taxonomy patterns defined in the fieldset don't display or custom one on a term edit page don't display ? Because I can't reproduce that...

I am trying this on a not clean install (if I find the time I will try with a clean install)
what I see is this
independent pattern on its own does not do anything on the taxonomy/term/xx pages
language specific patterns don't do anything either

- Cleaned up some code
- Changed the administration interface a little bit (sorry for that but problem is with 3 languages and many content types, it becomes quite a mess).
- Removed the precedently introduced fallbacks which are imo not needed right now to solve the localization problem, but of course we can add them later if needed.
- Added language neutral patterns instead

The last path #39 works great. I could translate all content types easily. But for taxonomy term pages, it lacks token for i18n category terms. The one I used for nodes and which works perfectly is not usable in taxonomy pages i18n-term-raw.

subscribe

this worked great on my site for content types! i'm not sure about taxonomies mentioned in #40
has there been any further development? this is really helpful for multilingual sites!

A big patch is not the best way to provide functionalities for that module because of its size, so i decided to create a module to provide that functionality.
I think this is the way to go because of the following:
- It uses hooks provided by page title module, so it doesn't add its own logic.
- It creates another menu tab for languages, so it doesn't modify the initial page title interface. Because of the potential big number of page title patterns due to number of languages and content types, i changed the interface to make it cleaner.
- You don't lose your initial page title patterns if you decide to enable that module; initial page titles are used as fall-backs and you should not need a clean install to use the module (still do that on a dev version of your website).

Now what to do with that module ?
- Make it part of Page Title so people can enable it if they want.
- Make it another module, not part of page title.
- Let people download it on my website if needed.

I'm not sure what's best, i'll wait for nicholasThompson to give us his opinion.

Meanwhile, you can download it here (attached).
Of course, Page Title is required as a module dependency.

This module only works with the 6.x-2.x-dev version of Page Title.

Thanks for your effort hles! Module works, it just needs some updating, for one, admin page needs to be in proper place, right now its in admin/settings/page-title/languages, but page title settings page is in admin/content/page_title so first tab on top of page goes nowhere. Also in administration menu modules page is set to "Per Language", probably should go under Content management > Page title. And form itself looks broken here, first there is General fieldset, then buttons, then Content types and Taxonomy fieldsets. So overall it works but needs some tweaking. Im using 6.x-2.3 of Page title module, so my "everything is in wrong place" could be because dev or any other version this module is written against has different paths.

LavaMeTender, you are right, this module was developped for the dev version as there are too many changes since the 6.x-2.3 version. This certainly explains your problems.

I am keeping track of this thread and I appologise for the lack of stable release recently. I'm working on the Views integration and it's a difficult task as Views has no easy/official API for other modules to "hang off" it. There is plenty of API to extend Views and what it offers, but little in the way of being able to run alongside it.

This is really exciting! Is it ok to use the .zip in #43? Or should I wait for a patch to use with 6.x-2x-dev?

use and provide feedback
and hopefully this code gets in the core module

Subscribing - I tested #43 and it works great.
@hles - Have you been able to further develop the module? I would love to try another version or a patch to the Page Title module.

Regards

Well, right now the module does pretty much all i need and probably what people need too. I don't mind working more on this a bit more if needed, but i don't think it's really worth it because of the state of Page Title module right now (understand work on D7 version, no recent stable D6 release, discussionof a merge with nodewords-meta tags etc)

I tried #43 (enabled like all other modules) and got the below fatal error at /admin/settings/page-title/settings

Fatal error: require_once() [function.require]: Failed opening required 'sites/all/modules/i18npagetitle/page_title.admin.inc' (include_path='.:/usr/share/php:/usr/share/pear') in /srv/www/example.com/public_html/includes/menu.inc on line 346

I flushed cache and ran update.php

/admin/settings/page-title/languages works fine.

Is there anything I may be missing?

Thank you!

Update: It seems like the module changes /admin/settings/page-title to /admin/settings/page-title/settings
And the added /settings makes the error show.

Also, I entered new page titles into /admin/settings/page-title/languages but it doesn't seem to work.
The fallback pagetitle from /admin/settings/page-title is used even though I put in new ones at /admin/settings/page-title/languages

Is anyone else experiencing these problems?

YK85, are you using the 6.x-2.x-dev version of Page Title ? The module will only work with that version.

Hello,

Yes, I'm using Page Title 6.x-2.x-dev
The link to Page Title settings when using Administration menu module is directed to /admin/settings/page-title/settings

/admin/settings/page-title/settings = fatal error
/admin/settings/page-title = still works, but have to manually type in url has the link to the settings goes to url that shows fatal error

Hope this helps to troubleshoot the problem!

Thank you

D7 ?

@YK85: Please, try this updated version as it should fix both your problem and a weight problem in settings mentioned previously.

I am attaching the latest version here for the last time. I have created a sandbox http://drupal.org/sandbox/hles/1142122 for this module. The name of the module has changed as it was generated automatically according to the title i had provided for the sandbox.

Edit: Note that with the name of the module changing, this new version won't be able to keep previously set page titles per language. Saving the 'variable' and restoring it would do that though.

@hles: Using it with Page Title 6.x-2.x-dev the interface works fine, but it ignores the settings, at least for the front page. What I already set on admin/settings/page-title is ignored as well as what I did on admin/settings/page-title/languages.

Looking forward to testing a fully working version! I like the interface and thought you put into this.

As per #57

Hey guys,
I am willing to help here, can you give me an example of what is not working exactly ?
When you say "it ignores the settings", does it mean it is not even saved in the form ? Have you tested that on a clean install or did you just replaced the old version with the sandbox page's version ?
On a clean install, i can get anything working, with or without tokens, for any languages so i guess we can solve your problems.

Hi! In my case, settings were stored (for both modules), but not reflected on the front page. It was not a clean install, so I guess I should do more testing.

My issue (for a panels based site) was solved was solved by editing template.php:

if (module_exists('page_title')) {

$vars['head_title'] = page_title_page_get_title();
}

I got Drupal 7 and it will by nice if patterns could be checked like Multilingual Variable in here admin/config/regional/i18n/variable.

subscribe

Hi again,

New version from #56 looks great, interface is perfect for now. Problem is that configuration form is in the wrong place (not under Page title with Admin menu) and code is off. For example, in function page_titles_per_language_page_title_pattern_alter there is $default_pattern_key variable. First it gets assigned front page pattern and then it gets overwritten with node pattern, since front page is also a node. Moving Frontpage part of code below User code seems to work, will test and provide patch...

I take back menu issue as after clearing cache for Admin menu interface is reachable perfectly. On other issue, this simple change seems to make it all good (patch is for module @ #56).

Is there any version for Drupal 7 ??

Thanks for #56 it works nicely on my site. Only the thing is that isn't it possible to make also "default" multilingual? So then we can include multilingual site name in page title of for example registration page or UC cart pages.

Is there Drupal 7 multilingual support for page titles?

The D6 branch is no longer supported so no new features will be added.