lfeditor issueshttps://gitlab.sgalinski.de/typo3/lfeditor/-/issues2024-03-22T10:24:03Zhttps://gitlab.sgalinski.de/typo3/lfeditor/-/issues/75allow my_ext/ext_localconf.php for language override configuration2024-03-22T10:24:03ZDavid Menzelallow my_ext/ext_localconf.php for language override configurationRight now, the LFEditor can be configured to override the language files. The path can be set in the extension configuration but only relative to the root folder public/...
Would it be possible to allow to set those override declaration...Right now, the LFEditor can be configured to override the language files. The path can be set in the extension configuration but only relative to the root folder public/...
Would it be possible to allow to set those override declarations in an extension specific `ext_localconf.php` file?
documention: https://docs.typo3.org/m/typo3/reference-coreapi/11.5/en-us/ExtensionArchitecture/FileStructure/ExtLocalconf.html
`It should contain additional configuration of `$GLOBALS['TYPO3_CONF_VARS']`.`
Which is for example:
```
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['EXT:news/Resources/Private/Language/locallang.xlf'][0] = 'EXT:my_ext/Resources/Private/Language/override_ext_news_locallang.xlf';
```
Maybe if the editor prefixes the path with `EXT:` and sets a path like `EXT:my_ext/ext_localconf.php`?
Right now the file path for those overrides points to `public/typo3conf/LFEditor/Configuration.php` and LFEditor has to be installed. If you have LFEditor just as an dev requirement installed, that doesn't work because the production system doesn't know to look in this file for the additional configuration.
Is that possible?https://gitlab.sgalinski.de/typo3/lfeditor/-/issues/72avoid creating of CDATA[] sections and use escaped content instead2024-03-05T15:27:30ZDavid Menzelavoid creating of CDATA[] sections and use escaped content insteadUsing CDATA sections for the content is not recommended according to the official documentation:
https://docs.oasis-open.org/xliff/v1.2/xliff-profile-html/xliff-profile-html-1.2-cd02.html#General_CDATA
The current version 2.1 also recom...Using CDATA sections for the content is not recommended according to the official documentation:
https://docs.oasis-open.org/xliff/v1.2/xliff-profile-html/xliff-profile-html-1.2-cd02.html#General_CDATA
The current version 2.1 also recommends to avoid it:
http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#d0e8112
Special characters should be encoded as HTML entities like described here in the best practice examples:
https://www.w3.org/TR/xml-i18n-bp/#AuthCDATA
So, by default, I would suggest not to use the CDATA section and special characters should be escaped.
However, the user should have the option to use the CDATA section if needed. Maybe with a checkbox to activate/add the CDATA section to individual fields?https://gitlab.sgalinski.de/typo3/lfeditor/-/issues/71option to allow translation services (e.g. Google Translate, Deepl, ...) for ...2024-03-05T12:59:11ZDavid Menzeloption to allow translation services (e.g. Google Translate, Deepl, ...) for key translationsIf you have a lot of translation keys it could take some time to translate every key manually.
It would save time, if an editor has the possibility to translate a key via the Deepl API, Google Translate API or other services, just by pr...If you have a lot of translation keys it could take some time to translate every key manually.
It would save time, if an editor has the possibility to translate a key via the Deepl API, Google Translate API or other services, just by pressing a button.
Maybe translate the complete language file in one go or each key individually one by one, depending if a localization exists or if just some keys needs to be translated. Then the editor only needs to proof read and maybe make minor adjustments.
I saw this feature in this extension: https://extensions.typo3.org/extension/datamints_locallang_builderhttps://gitlab.sgalinski.de/typo3/lfeditor/-/issues/70Allow non-admin users to edit certain extensions/files only2024-03-05T11:38:38ZDavid MenzelAllow non-admin users to edit certain extensions/files onlyHi,
it is possible to restrict the display of language files to selected extensions. However, this seems to apply to both admins and none-admins (editors).
Is it currently possible to separate the display of extensions in the language e...Hi,
it is possible to restrict the display of language files to selected extensions. However, this seems to apply to both admins and none-admins (editors).
Is it currently possible to separate the display of extensions in the language editor for admins and non-admin users?
If an extension has several language files, e.g
```
locallang_backend.xlf
locallang_frontend.xlf
locallang_tca.xlf
```
would it be possible that editors can only edit `locallang_frontend.xlf` and not the other two language files?
A similar option exists in the extension translate_locallang, where you can add specific extensions for none-admin users AND add specific files:
```
# cat=basic//7; type=string; label=Allowed extensions for non-admin users (wildcard patterns, comma separated, e.g. acme_*)
allowedExts = *
# cat=basic//8; type=string; label=Allowed filenames for non-admin users (comma separated, empty=all)
allowedFiles =
```
Unfortunately, this extension does not have the option of a tree view, which is very useful for keeping an overview in the LFEditor.
So, as summary:
Is it possible to restrict extensions and their files to none-admin users and if not possible, is such a feature possible to integrate?