Project

General

Profile

Actions

Feature #56953

closed

custom locallang.xml

Added by David Bruchmann about 10 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Extbase
Target version:
Start date:
2014-03-16
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

Using a custom locallang.xml with any extension on the first view looks like a feature-request.
As some translations maybe required but not present it's more than that: it's a bug.

Ok, what it is about now in detail?
For an extension (news) even already translated in many languages I need another translation and I never get it running without changing the locallang.xml in the extension itself.
I know, there must be a way how to do it without changes at extension or extbase but that's still not the issue.

The Issue is that the path to the default locallang.xml always is hardcoded and can't be overriden by configuration. So any other translation file will overwrite the values, it won't be loaded instead but additionally.

         static protected function initializeLocalization($extensionName) {
                 if (isset(self::$LOCAL_LANG[$extensionName])) {
                         return;
                 }
                 $locallangPathAndFilename = 'EXT:' . t3lib_div::camelCaseToLowerCaseUnderscored($extensionName) . '/' . self::$locallangPath . 'locallang.xml';
         ...

I wish a solution by configuration:

if (!$someConfigPath){
$locallangPathAndFilename = 'EXT:' . t3lib_div::camelCaseToLowerCaseUnderscored($extensionName) . '/' . self::$locallangPath . 'locallang.xml';
} else {
$locallangPathAndFilename = $someConfigPath.'locallang.xml'; // i.e. fileadmin/whatever/locallang.xml
}
Actions #1

Updated by Georg Ringer about 10 years ago

  • Status changed from New to Closed

you got with 6.1 to options:

1st: use the property extensionName to define a different extension key
2nd: use a full path in the property key like @LLL:EXT:fo/bla.xml:title"

if not enough, don't hesitate to open the issue again

Actions #2

Updated by Markus Klein about 10 years ago

  • Status changed from Closed to Needs Feedback
Actions #3

Updated by David Bruchmann about 10 years ago

@Georg
the 1st hint is at least a way how to solve it without the need to reference each translation with full path.
So the 2nd hint is possible but requires always the full path and with many translations it's getting much code and more difficult to read and maintain.

@Markus
Don't know about the "Needs Feedback".
In my opinion Georg showed a working way but it's not really smart. So I still wish an option to change it resembling to my proposition. Like this it would be even easy to configure different translation files depending on the page-tree, example: common page for elder people (yes for adults but it's not an "adults-page" required ;-) ) so some expressions are more difficult, another page-tree for kids and the words are easier.
My need is more basically and just related to a missing language in the translations, so if you don't see need for my example, the need for implementation of other languages still is to difficult or just not smart.

Actions #4

Updated by Alexander Opitz over 9 years ago

  • Status changed from Needs Feedback to New
Actions #5

Updated by Morton Jonuschat over 8 years ago

  • Status changed from New to Needs Feedback

Isn't this solved using $GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride'] - it allows overriding some or all labels using an own XML/XLF file?

$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['path/to/originalTranslationFile.xlf'][] = ’path/to/otherTranslationFile.xlf’;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['fr']['path/to/originalTranslationFile.xlf'][] = ’other/path/to/fr.otherTranslationFile.xlf’;

A bit more background: http://xavier.perseguers.ch/en/tutorials/typo3/articles/managing-localization-files.html#c962

Actions #6

Updated by Alexander Opitz about 8 years ago

What's the state of this issue?

Actions #7

Updated by David Bruchmann about 8 years ago

The way Xavier described with using "$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']" is a bit inflexible.
It always requires a language setup for each translation file and you can't just use something like de_DE_formal and de_DE_informal as it will search for corresponding locals.
At least it will show an error in the admPanel about missing locals and I don't know if without these locals the files will be loaded.

Furthermore you need a setup in the ext_localconf.php or another low-level configuration, and AFAIK you can't change the settings of $GLOBALS['TYPO3_CONF_VARS']['SYS'] in the pageTree by TypoScript.

So a really smart solution seems still missing.

Actions #8

Updated by Alexander Opitz almost 8 years ago

  • Tracker changed from Bug to Feature
  • Status changed from Needs Feedback to New
  • Target version set to 8 LTS

Changing to a feature request.

Actions #9

Updated by Tymoteusz Motylewski over 7 years ago

@David, pagetree related labels you can change in the User TS.
Please be more specific what is the issue, or what the requested feature is about.

Actions #10

Updated by Riccardo De Contardi about 7 years ago

  • Target version changed from 8 LTS to 9.0
Actions #11

Updated by Riccardo De Contardi over 6 years ago

  • Status changed from New to Closed

I close this ticket for now:

- There has been no activity since a long time
- A better solution would be probably to add a hook allowing for fetching labels from custom source. Feel free to reopen the ticket (or open a new issue with a reference to this one) and provide a patch if you think that it is still needed.

Thank you

Actions

Also available in: Atom PDF