First group looks like it was forgotten in the PR. They are fine to be removed.

The other strings are used in the permission tab of the fields and field groups.

Merged by review

@infograf768 you need to relook @ this jm.. at leas the last 2 groups are actually used by "access.xml" for the core.delete action and others.
Bear

On 20-Jan-17 08:10, Thomas Hunziker wrote:

Merged by review

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#13659 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABw66aUhqnLbgla41od3OfftDY0Ec91cks5rUMBfgaJpZM4LpUob.

Further it looks like the first group is used by com_fields...
[/image]

Those strings either have to come from the plugins, or not be translated at all. It doesn't make sense to have them in com_fields as it would only work for core fields. So the removal is correct.

@laoneo Do you have an idea how we can use the plugin language strings to translate the field type in the fields list?

Look at Smart Search and how it deals with getting translations from plugins.

In fact, we should NOT imho translate the $item->type.
This implies that it also should not be translated in the dropdown and should not have any caps.
Example of what I think we should get for color:

PLG_FIELDS_COLOR="Fields - Color"
PLG_FIELDS_COLOR_LABEL="color"
PLG_FIELDS_COLOR_XML_DESCRIPTION="This plugin lets create new fields of type 'color' in the extensions where custom fields are implemented."

I can make a patch for that.

Currently it is translated in the dropdown.
I honestly don't care much if we translate it or not, But it must be consistent.
I can see arguments for both. For most of the current types they equate to a HTML element. There a translation may not make much sense, but a type can as well be something completely different, eg a gallery or a player, then a translation would make sense imho.

This is what I propose;
Not translate the field type in the manager

Translate it partly in the plugin, i.e. for French:
PLG_FIELDS_TEXTAREA_LABEL="Zone de texte (textarea)"

which would give for example:

@Bakual
What do you think?

It get's translated here https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_fields/libraries/fieldsplugin.php#L52

core fields actions is exactly what they are used in.

@N6REJ The actions aren't affected by this PR. They have to stay in as you said ?

@laoneo That's for the dropdown. In the manager list, the type tries to translate it in another way: https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_fields/views/fields/tmpl/default.php#L155-L159, taking keys from "COM_FIELDS_TYPE_" which obviously will not work for the plugins. It falls back to the untranslated type of the field. So currently that code is useless ?

But it needs to use the same patter as the type field or?

I think it would make sense

@laoneo @Bakual
I will make a PR later today where both Translation and field type will display in the dropdown.
The field type will be a variable in the plugin lang strings.
Example:

PLG_FIELDS_TEXTAREA_LABEL="Zone de texte (%s)" ///for French and PLG_FIELDS_TEXTAREA_LABEL="Textarea (%s)" ///for en-GB

Code in fieldplugin.php will be something like:

			if (JFactory::getLanguage()->hasKey('PLG_FIELDS_' . $key . '_LABEL'))
			{
				$data['label'] = JText::sprintf('PLG_FIELDS_' . $key . '_LABEL', strtolower($key));
			
				// Fix wrongly set parentheses in RTL languages
				if (JFactory::getLanguage()->isRTL())
				{
					$data['label'] = $data['label'] . '‎';
				}
			}
			else
			{
				$data['label'] = $key;
			}

Will use only the pure field type in the Fields list column for now.
If judged necessary, we may add later a new method in the helper to load all fields plugin lang files to display also Translation (field type) in the column.

Honestly I would not add the field type as it is a technical thing where the end user doesn't care about. If extension developers are creating custom fields with some more complicated names then the label can look more confusing than it will help. Perhaps we can add the plugin name for better recognition.

Custom fields are technical things and an end user who does not understand what is a field type would anyway be lost.
Anyhow, if this proposal is not accepted, I will not lose time making a PR.

What do you think about the plugin name?

Why use the plugin name? It adds "Fields - " and it is useless.
The Label is perfectly fine, once the code I propose is used. Showing the "real type" next to the Translated Label is a good solution for me.

What do you think about the plugin name?

Nah, because the plugin in theory could have more than one field type.

Made a PR (which also corrected an error for the user field as it is not multiple and has no plugin settings) #13710