@wilsonge Shall we wait until this later pops up in 4.0-dev, or shall I make a PR for 4.0-dev, too?

Update: I've decided to make a PR for J4, too. Feel free to close that one if you expect merge conflicts.

Note: it is important to remember that the strings values here are unrelated to the field values.

And that is why it was wrong. In this case they absolutely must be.

Yep.

Good afternoon! In order for the match to be the correct match on all lines, I would also prefer to make changes to the language/en-GB/en-GB.mod_weblinks.ini:

MOD_WEBLINKS_FIELD_FOLLOW_DESC="Robots index - allow to follow or not."
MOD_WEBLINKS_FIELD_FOLLOW_LABEL="Follow/No Follow"
...
MOD_WEBLINKS_FIELD_VALUE_FOLLOW="Follow"
...
MOD_WEBLINKS_FIELD_VALUE_NOFOLLOW="No follow"

@infograf768 Do we maintain the language strings for weblinks only in the weblinks repo? Or only here? Or both?

Good afternoon! In order for the match to be the correct match on all lines, I would also prefer to make changes to the language/en-GB/en-GB.mod_weblinks.ini:

MOD_WEBLINKS_FIELD_FOLLOW_DESC="Robots index - allow to follow or not."
MOD_WEBLINKS_FIELD_FOLLOW_LABEL="Follow/No Follow"
...
MOD_WEBLINKS_FIELD_VALUE_FOLLOW="Follow"
...
MOD_WEBLINKS_FIELD_VALUE_NOFOLLOW="No follow"

@brianteeman What do you think? To me it seems to be a bit diffrent for weblinks regarding the label and description and the values. It could be ok like it is. What do you recomment?

@Kostelano It might be better to do that in a separate PR because it concerns weblinks, which

1. was not mentioned in the issue handled by this PR, and
2. has an own GitHub repository where it might be necessary to change the language string, too.

no idea, check the code

I have tested this item ✅ successfully on cbd7192

Looks like my comment was not understood. Lost in translation I guess.
The field is

			<field 
				name="robots"
				type="list"
				label="JFIELD_METADATA_ROBOTS_LABEL"
				description="JFIELD_METADATA_ROBOTS_DESC"
				>
				<option value="">JGLOBAL_USE_GLOBAL</option>
				<option value="index, follow">JGLOBAL_INDEX_FOLLOW</option>
				<option value="noindex, follow">JGLOBAL_NOINDEX_FOLLOW</option>
				<option value="index, nofollow">JGLOBAL_INDEX_NOFOLLOW</option>
				<option value="noindex, nofollow">JGLOBAL_NOINDEX_NOFOLLOW</option>
			</field>

What I meant is that whatever the spelling of the value of the lang strings JGLOBAL_, i.e. with caps or no caps, the correct value is inserted in the html.
It was a Note, which meant I did not oppose the patch, just made it clear what happens.

I did understand that comment.

yes it was lost in translation

If these language strings shouldn't be translated, then why are they language strings in the first place?

If these language strings shouldn't be translated, then why are they language strings in the first place?

Good question. I have no idea.

Because a mistake was made in the past

Afaik it is the same for many fields.
Example:

; Database types (allows for a more descriptive label than the internal name)
MYSQL="MySQL (PDO)"
MYSQLI="MySQLi"
ORACLE="Oracle"
PGSQL="PostgreSQL (PDO)"
POSTGRESQL="PostgreSQL"
SQLITE="SQLite"

Now, let's say we do that

		<field
			name="robots"
			type="list"
			label="JFIELD_METADATA_ROBOTS_LABEL"
			default=""
			validate="options"
			>
			<option value="">index, follow</option>
			<option value="noindex, follow">noindex, follow</option>
			<option value="index, nofollow">index, nofollow</option>
			<option value="noindex, nofollow">noindex, nofollow</option>
		</field>

It does work. The drawback is that these now display as untranslated when debug language is on.

To get something very clean, we would need some code preventing debug lang to choke on these.

@brianteeman @infograf768 Would it be a b/c break not to use language strings at all for the values in PHP code, and mark the language strings as deprecated for J4 in the J3 language file with a comment, and in J4 remove the strings?

We do have already translate_label and translate_description in FormField.
Maybe we could add a translate_option ?

@infograf768 I have no knowledge on form fields so would need advise for that.

Would it be a b/c break not to use language strings at all for the values in PHP code

The strings are not used in php afaik, only the option values. This is what I tried to explain in my first comment.

		if ($this->params->get('robots'))
		{
			$this->document->setMetadata('robots', $this->params->get('robots'));
		}

There would be no b/c break and it would make life much easier for translators as it removes strings that appear to need translating. (especially for new translations where the count of strings to translate can be daunting)

Sorry I was not clear. I meant change the PHP (or XML) so it uses the hardcoded values also for display of the options in the drop down instead of language strings.

@richard67
This is what I did above (in the xml)
#29612 (comment)

the drawback being the debug lang

@infograf768 I see ... well it seems we really need something to switch off translation for the option of particular fields. (Which is what I think the "translate_option" would be, right?)

(Which is what I think the "translate_option" would be, right?)

Yep, if it is possible. I tried some stuff but I failed. For label, hint and description we deal with a single element and the code is easy. For options it looks more complex as it would have to be done per option.

@infograf768 So what to do with this PR here and the other one for J4?

That really should be left to its own PR. Its a nice to have fix and doesnt
prevent this one from being merged

Merging on review and combined with the two good tests in #29613 (which is exactly the same PR)

Not exactly the same ... the J4 PR has the same change also in the API language file.