Add per-language patterns for multilingual node types

Do you use i18n module?

I think you might want this: http://drupal.org/node/176449

Thanks for the example - that explained it in a way that I didn't understand in your original description. This seems reasonable though I'm not sure where/how to fix it. Having multiple entry boxes for the alias patterns on admin/settings/pathauto would make an already confusing page even more confusing. That doesn't seem good.

But like I said, I'm open to the idea and to possible solutions.

also, as you point out, there are ways to workaround this now though they aren't perfect. You could add a taxonomy that people would select that said either cities or ciudades and use a pattern like [term-raw]/[title-raw] or something like that.

Better title.

"Support" can mean a lot of things.

Subscribing

mr.j - there is a patch. Please help testing if you can.

also updating compontent.

i'd be happy if it just passed $node->language to path_set_alias()... i'm not sure that all the settings fields are necessary...

also, now that 6.x is out should this get bumped up to that version and then backported?

maybe this should come after #210595: Create equal aliases for one translateble node in different languages ?

It should probably come after #210595: Create equal aliases for one translateble node in different languages and definitely in 6.x first and backported later (if at all...).

okay here's a cleanup and re-roll. i won't say i like the settings UI but at least the only people who'll have to suffer through it are those with multiple languages.

a few notes on setting up to test this patch. first, follow these steps to get your environment setup:

admin/build/modules

enable locale and translate modules

admin/build/block

enable the language switcher block

admin/settings/language/add

add a couple of new languages--say French and Spanish

admin/settings/language/configure

change the 'Language negotiation' setting to 'Path prefix with language fallback'

admin/content/node-type/story

edit the story content type and set the 'Multilingual support' setting to 'Enabled, with translation'--the setting is in the 'Workflow settings' fieldset

admin/settings/pathauto

add new, language specific patterns for the story node type. say article/[title-raw] for French and artículo/[title-raw] for Spanish. you might want to leave English blank for testing purposes,

node/add/story

create a new story, set the language to English and put 'EN' or english in the title to help distinguish the "translating" that you'll be doing

node/NID/translate

click the translate tab and then click the 'add translation' link on the French row. on the following page change the title so it includes FR or French. repeat for Spanish.

the big thing to keep in mind here is that for the paths are per language so for them to work you'll need to switch languages, hence the language switcher block. so if everything is setup right clicking on the Spanish link should take you to 'artículo/SP' and the French link 'article/FR'.

got the bulk updating working. i think it's previous behavior might have been buggy. it seems like if you had no matching patterns you'd still end up calling pathauto_create_alias() pathauto_max_bulk_update times.

here's a re-roll to clean up some conflicts the second fix for #210595: Create equal aliases for one translateble node in different languages

re-roll to chase HEAD.

@kenji_kun - can you review this?

@drewish - is this RTBC (so you don't have to chase head)?

greggles, i'd say code wise it's RTBC but i'm not too into the UI... i guess we could clean that up later.

chasing HEAD again.

Thanks drewish for keeping up with this.

I committed this to HEAD. I agree, if someone really hates the UI they can fix it but at least it's only the multi-lingual site-builders who will have the problems ;)

Some minor changes.
Default Type pattern if language is blank (like default node pattern).

@dvinegla - that seems like a new feature, not a small addition to the existing idea.

@drewish or @kenji_kin - care to comment on that?

Not real new feature,
if language don't have pattern, use de default node type pattern. If not default node type pattern, use the default node pattern.

dvinegla, if i understand you correctly that's the way it already works... if there isn't a nodetype-language specific pattern it uses the nodetype pattern and if that's not available it falls back to the generic pattern. are you saying there's a bug or that you'd like it to work differently?

as for the change to $fieldlabel... i think you really want to be using format_plural

So, this is either cnw or fixed.

It may be a bug, because if you don't need per-language pattern you can just specify default node-type pattern.
also you can only specify pattern for es / ca and use the default pattern for en / fr.

And the $fieldlabel should look like this?

 $fieldlabel = format_plural(count($languages) + 1, 'Pattern for all @node_type paths', 'Default path pattern for @node_type (applies to all @node_type node types with blank patterns below)', array('@node_type' => $node_name));

the format plural looks right, i'lll try to test out the patch later.

chasing HEAD.

marked #255596: disable multilingual path patterns as a duplicate of the thread since comment #21.

updated this a bit to add a language neutral pattern and only list the patterns if translation is enabled for the node type. this should address the problems raised by #255596.

@drewish - are you sure than neutral pattern is needed?

What is the diference with :

Default path pattern for Page (applies to all Page node types with blank patterns below):

and

Pattern for all Language neutral Page paths: ?

The Default pattern can be like this ?

Default path pattern for Page (applies to all Page node types with blank patterns below or neutral Page node types):

or something else.

the difference is that the default for all unspecified and the other is a specific language setting. perhaps you only want to create paths for language neutral nodes, if it's not a separate setting then there'd be no way to do that.

Ok, this seems right.

@dvinegla - "Ok, this seems right". Can you please also test the code and report back if it works for you?

Thanks.

@drewish - rtbc if/when you feel appropriate.

The patch from #19 caused a small regression on sites that don't use language #257473: the node/add node/nid/edit form doesn't get the checkbox/disable when default pattern is blank but with node specific pattern

The original if (isset($form['language'])) { test always passes because it contains an array, though an empty one, on sites without translation. I made a small change to check for a pattern rather than relying on the "else" case. I'd appreciate a quick review if folks could (at least review that it won't break your situations ;)

It won't cause a conflict with this patch, though the two may not apply perfectly at the same time.

#34

Neutral nodes don't use neutral pattern.
they use default node-type pattern if is set.

#35
it seems fixed since #21

If by "fixed since #21" you mean "my code has some fix for it" then perhaps that is the case, but since that hasn't been applied...

Also, using the "else" is not nearly as reliable as just testing for the !trim($pattern) which is why I prefer that...

You are true.
With my patch, i didn't pretend to modify existend code, only add additional checking.
your patch seems better.

Does it mean that only pathauto for drupal 6 will have support for defining different "autopaths" for different active languages?

@JordiTR - once this is working well for 6.x we can see about backporting it to 5.x. Your assistance testing the 6.x branch would be greatly appreciated so we can get it perfect.

i upgrated the pathauto to 6.x-1.x-dev 2008-May-16
anybody knows how to create alias to all language by default?
this is a single language content website. the following alias that belong to only one language are not expected as there are no url alias to other language. they need all become language=all.
System Language Operations
node/4 Chinese edit delete
node/27 Chinese edit delete
node/53 English edit delete
node/2 Chinese edit delete
node/49 All edit delete
node/50 All edit delete

For now, you can copy the same pattern to english and chinese.
Or apply #30 patch

@greggles - Thanks! I'm not creating sites with 6.0 still but I'll try to set a testing environment to see how it works.

@greggles: Did you intend to attach a patch to your comment #35? If so, I'm not seeing it... if not, the issue you're referencing is fixed, so this or any other patch is likely in need of a re-roll. :)

@Freso - I don't understand this issue all that closely (and feel it's being overloaded at this point) so I wanted to keep that "normal path" patch separate. The patch I mentioned in #35 was the patch in that separate issue.

The patches here don't alter the same lines as that one, but they come close so I'm not sure if any here will need a re-roll.

Comments to #47

- if (!empty($language)) is not needed, becase node->language always is set.

- use variable_get('language_content_type_'. $node->type, 0) instead of translation_supported_type($node_type) to don't make it translaton.module dependent.

- language of multilingual support disabled nodes, are set to language_default():

1. set English as default language.
2. enable multilingual support to Page.
3. set pattern for Page default : default_page/['title-raw'];
4. set pattern for Page in english: english_page/['title-raw'];
5. disable multilingual support to Page.

All Page nodes are path_alias to : english_pagag/['title-raw'] and you can't view /edit enghish pattern because multilingual support for Page is disabled.

to avoid this, variable_get('language_content_type_'. $node->type, 0) check is always needed.

- if (!empty($language)) is not needed, becase node->language always is set.

i'm not sure it matters in terms of code flow but for language neutral nodes $node->language == '' and empty('') == true.

- language of multilingual support disabled nodes, are set to language_default():

i don't think this is the case... wouldn't they be language neutral?

i'm not sure it matters in terms of code flow but for language neutral nodes $node->language == '' and empty('') == true.

$node->language is always '' or '$language'

the empty($node->language) means for ?

i don't think this is the case... wouldn't they be language neutral?

would be, but Drupal set it to default, instead of '' (neutral).

This is just a re-roll of #47 to clear offset (from #258314: Doxygen clean-up). Not tested or given proper review.

Did I mention it's 10 minutes to one... am? :)

Attached patch based on the comments below.

• Why was the string Pattern for all @node_type paths in @language replaced by Pattern for all @language @node_type paths? Such changes should go to #256340: String clean up if they're really wanted. We don't want to upset translations (or translators) (too much)...
• Given further thought, I assume the above is due to the "Language neutral" bit that is introduced. However, this makes it really hard to translate to e.g. Danish. Instead, I've added a clause checking whether there's a language specified, and if not, use the text Pattern for all language neutral @node_type paths.
• On another note (or node, as it would be during the testing), going to node/X/edit gives notice: Undefined index: #value in /srv/http/localhost/htdocs/drupal6/sites/all/modules/pathauto/pathauto.module on line 266. with the old patch. This was fixed by keeping this part of the code as it was before patch.
• After playing with making English and Danish and Neutral specific rules, I found that Pathauto (plus the attached patch) behaved as expected. Drupal didn't though - whenever I set the node to English, Pathauto would save the appropriate alias into the alias table, but Drupal would still use node/X as the path. :( However, I believe this to outside the scope of this issue.

So, yes. Please review and test the attached patch. I think it's this close to being committable, so now's a good time to chime in if you agree or disagree! :)

I'm using 6.x-1.0 and I have multiple languages set up. I have only entered default paths for me nodes, e.g. I have no language-specific paths set in the Pathauto settings. Despite this, the aliases are language dependant. If I create a Dutch node, the alias is Dutch as well. If I create an English node, the alias is English. If I'm right this means that when going to the domain used to view my site in English those aliases won't work.

pathauto 6.x-1.0 have language bug, use 6.x-1.x-dev version instead.

@Xano: Are you using any "hard strings" in your patterns (e.g. "content/[title-raw]")? Or are you only using tokens in your patterns (e.g. "[menupath-raw]/[title-raw]")?

Xano, are you trying out the patch in #53?

I'm using both strings and tokens in my paths.

@drewish: Damn. Must have overlooked the very last list item in #53. That's exactly what's happening here. Tonight I'm busy, but if I don't forget it I'll check out that patch this weekend (hopefully sometime tomorrow).

@Xano: And the hard strings are translated as well? That sounds rather odd, as Pathauto wouldn't currently know what to translate them to... (without the patch that is, but it sounds like you're not trying with the patch... ?)

No, they're not being translated. Although I have set a general alias (non language specific alias, that is) for content type X, pathauto will only save this alias for the node in the language it was created in. In other words: If I create a node in English an alias will be created for it. This alias will however not be used when the user's display language is set to Dutch for instance. When selecting another language than the source language there is no alias and the /node/nid path will be used by Drupal.

What I'm trying to say is that if there's no language specific alias pattern set for pathauto, pathauto should not link the automatically made alias to the language the node's been created in.

And no, I haven't checked out the patch yet. I'm terribly busy moving content from my old site to my new site as I'd like to have this done before my old contract ends (which is sometime this weekend)

@Xano: Ahh! Alright, I think I'm beginning to follow you. Sorry for being dense. :) Well, I think you should a) test this patch and see if it fixes it, and if it doesn't, then b) file a new issue. The issues are very probably related, but they're not the same, and it would be overloading the purpose of this feature request, to add this bug it.

Good luck with porting your site! (I'd recommend you to use one of the 6.x-1.x-dev tar balls, as they contain a few bug fixes etc. from the 6.x-1.0 release. The -dev branch is pretty much stable, as we're only checking in patches that have been "reviewed & tested". Also, once you have some time to spare again, help towards getting 6.x-1.1 released would be greatly appreciated. :))

Alright, since noone's apparently willing to review this, it has been committed in the hope that people will file any bugs they run into.