[jhelp] Glossary Joomla 4

[YGomiero]

Joomla 4 :
Do not translate the line in the joomla.ini file
administrator/language/xx-XX/joomla.ini

JHELP_GLOSSARY="Glossary"

With the current version (J4.0.2), there is an error in the help section of Joomla 4 because the translation term is included in the url of jdoc, necessarily on a page that does not exist.

The problem also occurs on all translation packs.

line 35 : administrator\components\com_admin\tmpl\help\default.php

<?php echo HTMLHelper::_('link', Help::createUrl('JHELP_GLOSSARY'), Text::_('COM_ADMIN_GLOSSARY'), ['target' => 'helpFrame']); ?>

[conconnl]

Correct, that is why they are hidden and also mark as "DONOTTRANSLATE"
For some reason they are automatically translated.
Need to find the correct way to stop this, without increasing the work for translators.
cc @HLeithner

[conconnl]

@YGomiero I checked Joomla 3 translations as well.
This string is also translated in that version for various languages for years.
Doesn't that break J3?
If not, why....?

[HLeithner]

Seems we need a comment here? https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/language/en-GB/joomla.ini#L863 but isn't this true for all other JHELP entries too?

[conconnl]

The comment doesn't stop the auto-translation bit.
Duplicate strings are translated automatically, even when they are Hidden. Just had a whole discussion with Crowdin about it. A comment is just for the translators themselves.

[HLeithner]

and can we stop crowdin todo this?

[conconnl]

Yes, but that would mean an additional 4700 strings to translate. There are that much string in the CMS which have the same value.

Another option is to Hide all duplicates with strict comparison. Which will not copy translations if the string constant and value are not the same as one in another file.
This will of course also increase the amount of translatable strings.

Another option would be a language file for the JHELP and not have it in Crowdin, that will increase the Core with 1 file.

[HLeithner]

looks as the last option would be the best

[brianteeman]

Duplicate strings absolutely should not be translated automatically. If they were really duplicates we would have used a global. Just because the english for two strings is the same doesnt mean that it should be translated the same because the context is different.

Yes, but that would mean an additional 4700 strings to translate. There are that much string in the CMS which have the same value.

That cannot be correct

[conconnl]

Duplicate strings absolutely should not be translated automatically. If they were really duplicates we would have used a global. Just because the english for two strings is the same doesnt mean that it should be translated the same because the context is different.

Yes, but that would mean an additional 4700 strings to translate. There are that much string in the CMS which have the same value.

That cannot be correct

I fully agree, it's a change compared too what has been done for the last couple of years with Joomla v3.
Personally I would gladly switch the duplicate option off.
As you know, the moment you change how things were for the last couple of years, we have various people (translators and non-translators, who start to complain).

[infograf768]

Reminder of a former discussion
#30803

A specific file would do the job indeed.

As for Crowdin, I have already told what I thought about this app... Keep it simple at least. Indeed take off the duplicate option.

[conconnl]

Ok,
So I tested various languages in Joomla 3.9, which were created based on the configuration decided by the maintainers of that version. Where the decision was to auto-translate duplicate values.
Guess what, it's broken in J3 as well for a very long time even though a discussion has been performed about it.

Looking at the facts.

• Same words do not have to mean same context and thus not a duplicate.
• Auto-Translation should not happen including approval, especially not for hidden strings.
• Changes in a certain string because of the context, should not have influence on other strings with the same value.
• Probably other reasons.

My conclusion is that the "Auto-Translate Duplicates" option should be disabled at least in the new platform for Joomla 4.
What to do about the J3 structure, I don't know yet.

PS:
Translators and Proofreaders will get some additional work, as they need to check more strings.
The system makes suggestions from Translation Memory, so it's not that they need to manual translate the strings again.

Any objections?

[brianteeman]

I agree with your conclusion and tbh surprised that auto-anything was ever turned on for a string

I cant believe your figure of 4,700 though.

[conconnl]

You get there fast.
There are for example 4 strings with the single word Glossary.

[Bakual]

Auto-translating actually works fine in most cases. Afaik we had it set in J3 to "autotranslate, but show", so translators were still able to translate it, in case it was different. In most of the cases however, duplicate strings are the same in all instances and thus it reduced work a lot.
Especially also when taking into account the different branches and application (site/admin).

So I would not change that easily.

As for the help strings, it may be interesting to know if they are actually still used. From what I remember they were used for supporting language specific help sites, provided by the translation teams. Nowadays we have all of them on our own Joomla property and it is translated there. So from my understanding we could as well hardcode the strings somehow without using language strings. But I may miss something here.

[conconnl]

@Bakual is correct, proofreaders can still change the translations if needed.
Having them pre-filled based on other strings do not block possible changes.
The JHELP strings are a problem in this flow, as they should not be translated at all, but hold the same value as a few translatable strings.

A fast solution is splitting the file, which results in not providing the strings into the translations flow.
There fixes any broken JHELP link because of translations, after new packages are deployed.
I create a PR for that and we can always look at removing the strings completely or any other solution.

[Bakual]

I've started a PR to show how the strings could replaced by hardcoded keys. At least for most of the strings that would work easily.

[chmst]

Closing as there is a PR, please test #35479