Multi-language site profile : Add language / rename language code

[harikt]

I did wrote about the issue over https://processwire.com/talk/topic/31011-adding-language-changing-language-is-not-reflecting-on-the-front-end/

What I noticed is when new language is added, it is not adding value to the page id 1, which have a name* field and is missing the new value.

The behaviour when we rename the existing language code ( de => uk ) is not updating this field value.

[ryancramerdesign]

@harikt The language name (in Setup > Languages) and the URL prefix that it uses are two different things. For instance your language name might be "spanish" or "es-br" but your URL prefix might just be "es". Though it's also fine if they have the same value. But to edit the prefix that is used in the URL, you would have to edit your homepage and then click on the Settings tab. There's more about this here.

[BernhardBaumrock]

@ryancramerdesign while I understand from a technical point of view that language url values are setup on the home page I also see that this could be improved a lot from the user perspective. I think it would be great to have an inputfield on the language edit page that makes it possible to set the url value (example.com/de) directly there. It could internally just set the value on the homepage, but as a user I think it's much more intuitive to define the language url value under "setup > languages > en > url value" than going to "Pages > Home > Edit > Settings > Page Name"

[BernhardBaumrock]

Or maybe even a hint to instruct the user what to do in case he/she wants to change the language slug would already be a great addition in my opinion :)

[harikt]

@ryancramerdesign anyway there is a bug or people may not understand what went wrong.

I added a new language with title Test and name as test.

As you mentioned about the home page settings contains the prefix, I checked there.

This is pointing to en . As a user I expect it to be same as the name I have entered. I can ignore about the edit, but at-least the add should work as expected.

[ryancramerdesign]

@BernhardBaumrock The page names in this case are properties of the page, not of the language. If your site has 100 pages then all 100 of the page names for each language are edited on the Settings tab of that page editor. That's also where they are enable or disabled for each page. It would be pretty inconsistent if we said "edit them all here, except for the homepage, which you should edit over there instead."

@harikt I think I don't understand what you are seeing yet. If you think there is a bug, can you describe in more detail how to duplicate it? If you added a new language named "test" then edited the homepage (or any page) then you should have an input for the page name in that language. In your screenshot it shows "en" for your new language, overlapping your other language. That's fine and page names are allowed to overlap for different languages (some words are spelled the same in different languages). But to make it easier for PW to detect a language, it would be preferable to use something other than "en". Or if you want to use "en" then delete the "en" for your default language (which would be the most common setup). Also have a look at the additional settings in Modules > LanguageSupportPageNames.

[BernhardBaumrock]

@ryancramerdesign I think you misunderstood my request! Also I think your example just shows one use case, but I think my mentioned use case is much more likely. Who ever wants to change 100 page names??

But I don't want to hijack this thread so I created a request that should explain what I tried to say: processwire/processwire-requests#557

[harikt]

@ryancramerdesign , this is what I am doing. Not sure if this is expected.

Adding a language :

I added a new language with title and name as shown in screenshot.

Once I added the language, I am editing the home page and moving to Settings tab.

In this view, I was expecting the last text field value with label Test to be test and not as en. If this behavior is correct, we can close the issue,

[BernhardBaumrock]

@harikt I just tested and can confirm this:

My default language is Deutsch with no url segment. The newly added language "ProcessWireish" has no url segment setup yet, so it shows no segment:

I then added "de" as url segment of the default language and hit save:

--> Result is it shows /de/ for the ProcessWireish language as well. Which is misleading at least.

@harikt not sure if you are just reporting the behaviour or also need a solution? To solve this you can just override the url segment with your own (test in your case, pw in my case):

[harikt]

@BernhardBaumrock I got the solution. I was expecting this as a bug which was misleading when you add a language. Now I know the details. Thank you all. A reply from forum also tells this is expected. https://processwire.com/talk/topic/31011-adding-language-changing-language-is-not-reflecting-on-the-front-end/#comment-247339 . So @ryancramerdesign you can take the necessary action for the issue.

Thank you all.

[ryancramerdesign]

Okay I changed the 'body' field to use TinyMCE inline mode (variable height) and a good place to find it is on the homepage, so the window is now open to http://localhost:8888/test-processwire/processwire/page/edit/?id=1

[matjazpotocnik]

@ryancramerdesign sorry, I don't understand, what is this link?

Following up — confirmed this isn't a data bug (the fallback value never gets persisted; there's already a check on save that blanks it out if it matches the default). The actual actionable item from this thread is the UX confusion @BernhardBaumrock flagged: the field shows an inherited value with no indication it's inherited rather than explicitly set.

Patch attached adds a small note under any language name field that's currently showing a fallback value, clarifying it's inherited from the default language until overridden.

--- a/wire/modules/LanguageSupport/LanguageSupportPageNames.module
+++ b/wire/modules/LanguageSupport/LanguageSupportPageNames.module
@@ -736,12 +736,14 @@
 		if($page->id && !$page->editable('name', false)) $editable = false;
 
 		// add labels and inputs for other languages
+		$defaultLabel = $languages->getDefault()->get('title|name'); 
 		foreach($languages as $language) {
 			/** @var Language $language */
 			if($language->isDefault()) continue; 
 			$user->setLanguage($language); 
 			$value = $page->get("name$language"); 
-			if(is_null($value)) $value = $savedValue; 
+			$inherited = is_null($value);
+			if($inherited) $value = $savedValue; 
 			$id = "$savedID$language"; 
 			$name  = "$savedName$language";
 			$label = $language->get('title|name'); 
@@ -759,6 +761,13 @@
 			}
 			if(!$editable) $inputfield->attr('disabled', 'disabled');
 			$out .= $inputfield->render();
+			if($inherited && strlen($value)) {
+				// clarify that this value is only a fallback display, not yet an explicit setting for this language
+				$out .= "<p class='notes'>" . sprintf(
+					$this->_('Inherited from %s until you enter a different value here.'), 
+					$defaultLabel
+				) . "</p>";
+			}
 		}
 
 		// restore language that was saved in the 'before' hook