LanguageSupportPageNames.module has no setLanguageValue() method

[plauclair]

As far as I know, the name field is the only one which does’t have support for the setLanguageValue method. For the sake of making everything the same, I think this should be added.

[ryancramerdesign]

setLanguageValue is only a syntax used by TextareaLanguage and TextLanguage. A more reliable syntax with custom fields is to set the user's language, then set the value for that language. But even that won't work with setting the name field, because name is itself not multi-language at all.

When it comes to page names, try not to think of name as a field in PW. Think of it as the same thing that "name" represents in any other ProcessWire data type. Name is fundamentally different from custom fields. It's not far off from a page ID, in that it is part of a unique index in combination with the page's parent ID. The value of $page->name is never affected by the language. Only the page's path/URL is affected by the language. The appearance of being able to change the name per language is for UI reasons in the admin. There is no such thing as changing the page's name (per language) at the API level. When you install the LanguageSupportPageNames module it keeps track of new properties called "name123", "name456", etc., where 123 and 456 are language IDs. These are different properties from name. These never get substituted for the actual page's name except for the purposes of generating a URL. As a result, if you want to change how a page is identified in the URL at the API level, for some language other than default, you'd do it like this:

$language = $languages->get('de'); 
$page->set("name$language", "bier"); 
$page->save();

[plauclair]

Thanks Ryan, that’s indeed what I’m doing currently. Do you think having setLanguageValue might be a good thing to have though, for consistency’s sake? Is setLanguageValue even a common method? Looking quickly in ApiGen it doesn’t seem to be the case.

I work on multilingual website/apps most of the time, I really find setLanguageValue convenient when it’s available.

[teppokoivula]

I've worked with multilingual sites quite a bit, but admittedly not that much from the API side. I've been under the impression that setLanguageValue() is the way to go here too.

Other methods seem to me more or less hacky, in a "you'll have to know what's really happening behind the scenes first" type of way, which means that they may be logical once you know the tricks but even then won't necessarily seem truly polished (especially if different fields -- from users point of view -- behave in different ways).

Just my two cents.

[ryancramerdesign]

It's simply not possible to have a setLanguageValue attached to the 'name' field, because :

1. Name it is not a multi-language field– $page->name always returns the value in the default language, and that's required. Only the path/URL are multi-language.
2. Name is a string, not an object, and it needs to remain as a string. Think of the name as not far off from the page ID. This is PHP and we can't add methods to a string. :)

What I can do however is add setLanguageValue() / getLanguageValue() methods to the Page object itself (via add method hooks in LanguageSupport.module). That can abstract away any field-specific details needed for setting a value in a particular language, so I've gone ahead and added that in the commit referenced above.

[plauclair]

This is nice! Wish I could like on GitHub but here’s a try: 👍

[teppokoivula]

@ryancramerdesign: looks awesome, thank you! :)