User tests: Successful: Unsuccessful:
Pull Request for Issue #35416
The JHELP language strings within Administrator and API are moved to their own files.
These strings should not be translated, while the rest of the string in the file are needed to be translated.
Having them in their own files, makes it possible to ignore the strings completely in the translation flows and decrease the risk of breaking the Help Server within the Administrator.
Now the help screens are broken in the various languages, because the strings are translated, as they are made available for that purpose, while not needed.
Check if the strings are still loaded in the Joomla Administrator help pages.
The language strings are used within the help pages to buildup the URLs.
The language strings are still used within the help pages to buildup the URLs.
Category | ⇒ | Administration Language & Strings |
I'm not a developer, so I'm not going to play around in that area.
Now we have broken help pages in every other language then en-GB.
This is not a work around if you ask me, this is putting the strings in their own location and not mixed within "Required to be translated strings", which results in working translation packages and not broken help-pages.
Edit: The strings are used in the code.
Example:
line 35 : administrator\components\com_admin\tmpl\help\default.php
<?php echo HTMLHelper::_('link', Help::createUrl('JHELP_GLOSSARY'), Text::_('COM_ADMIN_GLOSSARY'), ['target' => 'helpFrame']); ?>
the api file is not needed. the strings were only there to keep the two joomla.ini in sync. now that they are in their own file you can just delete the new api/joomlahelp.ini
Labels |
Added:
Language Change
?
|
Category | Administration Language & Strings | ⇒ | Administration Language & Strings Libraries |
If the only way is to add a specific ini file, it should be loaded whatever the language and totally independent from the language packs.
I would place that help file in libraries/src/Language/joomlahelp.ini
and not in the en-GB folders
And always load it directly in language.php
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.
Opinions welcome. I could at least reduce the strings. Maybe even eliminate all.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-09-12 09:57:48 |
Closed_By | ⇒ | conconnl |
I think we should rather look into removing the need for them in the first place, before we move them around and do nasty workarounds.