I don't understand your problem. Component names are translated correctly.
If the name of your component is com_helloworld then the name of the language file is not en-GB.com_qwhelloworld.sys.ini.

The names are not correct in the database as shown in the images.

During the install the string COM_HELLOWORLD is not translated before it is stored in the #__extensions table, name column. Hence all component names are in the format COM_HELLOWORLD or com_helloworld

The translation happens correctly for modules and plugins.

Also ignore the typo you noted I will go, and change that now.

The names are not correct in the database as shown in the images.

During the install the string COM_HELLOWORLD is not translated before it is stored in the #__extensions table, name column. Hence all component names are in the format COM_HELLOWORLD or com_helloworld

It should NOT be translated in the database. It should only be translated when it is output.

What you are proposing would mean that it will always be stored as a language value and not a language key. Therefore it can not be translated

Then why is that happening for modules and plugins? I am on about the name and not element

You can clearly see in the images above this is happening for plugins and modules, it always has. It is just components that this does not work for.

Would you like me to re-upload my example images and add some annotations on them to make it easier to see the issue?

This table might help.

thanks

@brianteeman The image you have sent doesnt really help me. Is it a Joomla dump or a database dump?

If you look at eXtplorer though, you can see it has a translated name field. You will probably find it is using the <element> tag in its manifest. This is assuming this ouput matches the database fields.

If you look at the images I posted you can see Translated and non translated name fields.

compare the function storeExtension() in:

• joomla-cms/libraries/src/Installer/Adapter/ComponentAdapter.php

  Line 589 in e4e370c

  protected function storeExtension($deleteExisting = false)

• joomla-cms/libraries/src/Installer/Adapter/ModuleAdapter.php

  Line 310 in e4e370c

  protected function storeExtension()

They are different in how they handle the storing of the name.

They are different in how they handle the storing of the name.

The only difference i can see is that the handling of discovery installation happens at different places. But regarding storing the name I see no difference.

I am not an expert but:

module

$this->extension->name = $manifest_details['name'];

component

$this->extension->name    = $this->name;

The manifiest has probably already been parsed with the translator code.

$this->extension->name = $manifest_details['name'];

Is only done for the module when a discover installation.

For normal installations it looks the same as for the component, $this->extension->name = $this->name;.

You should also have a look on the if conditions around the assignment statements.

ok, I will find the code and paste it here as long as this issue doesnt get closed becasue no-one thinks this issue exists 😄

ok, I will find the code and paste it here as long as this issue doesnt get closed becasue no-one thinks this issue exists 😄

Thanks, maybe that could help.

But if the issue exists, then your approach or expectation to save the translated text in database is wrong, as already elaborated. It would never be possible to see the translation changing when changing backend language if we do that.

But if the issue exists, then your approach or expectation to save the translated text in database is wrong, as already elaborated.

It already happens, see my images above which no-one seems to look at 😒

It would never be possible to see the translation changing when changing backend language if we do that.

I never said that. It is upon the intial install, that the component's default language translation of COM_HELLOWORLD is used for the name column. No further updates are done to it, i.e. changing the default language in joomla.

I will find where the name is getting parsed in modules/plugins and why this is not happening with components using my trusty debugger.

I still dont know what the issue that you are trying to resolve is?

I am debugging the code to track what I need down. I think it will be easier if I find the code to help explain.

I have gone back to my orginal post before everyone was saying they could not see the issue.

A component will only install correctly if the name tag in the manifest is in one of the following formats. It must be the components element name either in lowercase or uppercase, perhaps a mixed version would also work.

<name>com_helloworld</name>
<name>COM_HELLOWORLD</name> 

unless you have the following tag which will overrides the name tag for the purposes of installing. in which case you can change the <name> tag to something else. ie <name>COM_HELLOWORLD_NAME</name>

<element>com_helloworld</element>

If you do not follow the rules above, the component appears to install but the menus are corrupt and they dont work, see below where I changed the name tag to <name>com_chicken</name> when the name of the component is com_qwdemobar. It should also be noted that the extension installed into administrator/components/com_chicken

Modules and plugins

• Modules and plugins do not have this limitation so you can use any <name> translation string you want without affecting the installation.
• Modules and plugins manifest have some extra code in the which I guess handles the element side of things.

<filename module="mod_helloworld">mod_helloworld.php</filename>
<filename plugin="helloworld">helloworld.php</filename>

so maybe joomla should

Use a string similiar to modules and plugins.

<filename component="helloworld">helloworld.php</filename>

So you cannot use any translation string you want in the <name> field unless you have the <element> configured.

The <element> field is only present in a component, so in the <name> tag issue is changed/fixed you could potential remove the need for <element> which no-one seems to use anyway and would bring all of the install types closer together.

I hope I have madew things a little clearer. It certainly helps when you dig into the code.

Thanks JCommunity

So if I understand correctly you want the core of joomla to be changed so that an extension will install that doesnt follow the documentation??

actually what I am asking for is for the documentation to be followed:

see https://docs.joomla.org/Manifest_files

The following elements can be used to insert metadata. None of these elements are required; if they are present, they must be a child of the root element.

Note: The <name> and <description> tags are also translatable fields so that the name and description of the extension can be shown to the user in their native language.

• In the case of components you must use one of the 2 formats I outlined above for the component to install correctly. This means that the <name> tag does more that represent the translatable name.
• it is true the strings outlined above can be translated
• If the code was correct I should be able to use anything I want such as <name>COM_HELLOWORLD_NAME</name>
• If you use the <element> tag you can then use any translation string you want in the <name> tag. This is not mentioned in the documentation.
• Modules and plugins do not use the <element> tag, they dont need to and it is component only.
• all translatable fields in Joomla do not define what the string must be called except in a component manifest.
• the <name> tag should not be involved in the file installation of the component.

At the very least the <element> tag should be made mandatory and the <name> tag should have nothing to do with the install procedure just like modules and plugins, and the documentation updated to reflect this.

I am sure this would be a small change to the installer code without much repercussion.

Thank you for raising this issue.

Joomla 3 is now in security only mode with no further bug fixes or new features.

As this issue doesn't relate to Joomla 4 it will now been closed.

If we are mistaken and this does apply to Joomla 4 please open a new issue (and reference this one if you wish) with updated details for testing in Joomla 4.
cc @zero-24

Closing for the reason stated above.