Document naming of .xlf files and what to use when

[sypets]

We usually / often have specifically named files for Language labels, but there are some specifics which are not documented (or I did not find it).

1. What file to use for what, usually we have:

• locallang.xlf
• locallang_mod.xlf
• locallang_db.xlf

The _mod file is often used in registerModule - should the labels for the backend module also go in there or in locallang.xlf?

2. The locallang_mod.xlf has some specific keys which are automatically used in the BE module if registerModule is used:

           <trans-unit id="mlang_tabs_tab">
                <source>Some label</source>
            </trans-unit>
            <trans-unit id="mlang_labels_tabdescr">
                <source>Some desciption.</source>
            </trans-unit>
            <trans-unit id="mlang_labels_tablabel">
                <source>Another label</source>
            </trans-unit>

This is not documented in TYPO3 Explained.

Existing documentation

This is existing documentation where this might be added:

• Internationalization + Localization: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Internationalization/Index.html
• (extension) file structure: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/FileStructure/Index.html
• backend modules: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/HowTo/BackendModule/Index.html
• naming conventions: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/BestPractises/NamingConventions.html

[sypets]

The TYPO3 core also has:

sub directories:

• Modules
• Form
• Report
• Module

a large number of files - different conventions :

find typo3/sysext/*/Resources/Private/Language/ -name "*.xlf" | perl -p -e "s/.*\/([^\/]*)$/\1/" | sort -u

• about.xlf
• BackendModule.xlf
• Database.xlf
• db.xlf
• debugger.xlf
• fileMessages.xlf
• InfoPageTsConfig.xlf
• locallang_alt_doc.xlf
• locallang_alt_intro.xlf
• locallang_analyzer.xlf
• locallang_browse_links.xlf
• locallang_cache.xlf
• locallang_ceditor.xlf
• locallang_column_selector.xlf
• locallang_common.xlf
• locallang_copytoclipboard.xlf
• locallang_core.xlf
• locallang_db_new_content_el.xlf
• locallang_db.xlf
• locallang_debug.xlf
• locallang_download.xlf
• locallang_em.xlf
• locallang_formEditor_failSafeErrorHandling_javascript.xlf
• locallang_formManager_javascript.xlf
• locallang_general.xlf
• locallang_info.xlf
• locallang_layout.xlf
• locallang_login.xlf
• locallang_main.xlf
• locallang_mfa_provider.xlf
• locallang_mfa.xlf
• locallang_misc.xlf
• locallang_mod_admintools.xlf
• locallang_mod_configuration.xlf
• locallang_mod_file_list.xlf
• locallang_mod_file.xlf
• locallang_mod_help.xlf
• locallang_mod_permission.xlf
• locallang_mod_site.xlf
• locallang_mod_system.xlf
• locallang_module_redirect.xlf
• locallang_module.xlf
• locallang_mod_usertools.xlf
• locallang_mod_user_ws.xlf
• locallang_mod_web_info.xlf
• locallang_mod_web_list.xlf
• locallang_mod_web.xlf
• locallang_mod.xlf
• locallang_objbrowser.xlf
• locallang_pages_new.xlf
• locallang_pages_sort.xlf
• locallang_preview.xlf
• locallang_reports.xlf
• locallang_reset_password.xlf
• locallang_show_rechis.xlf
• locallang_siteconfiguration_module.xlf
• locallang_siteconfiguration_tca.xlf
• locallang_siteconfiguration.xlf
• locallang_slug_service.xlf
• locallang_t3lib_fullsearch.xlf
• locallang_tabs.xlf
• locallang_tasks.xlf
• locallang_tca.xlf
• locallang_tcemain.xlf
• locallang_tsdebug.xlf
• locallang_tsfe.xlf
• locallang_ttc.xlf
• locallang_view_help.xlf
• locallang_webinfo.xlf
• locallang_wizards.xlf
• locallang.xlf
• ModuleInstallEnvironment.xlf
• ModuleInstallMaintenance.xlf
• ModuleInstallSettings.xlf
• ModuleInstallUpgrade.xlf
• siteconfiguration_fieldinformation.xlf
• wizard.xlf

[brotkrueml]

Actually, AFAIK the only file name that must have a strict name is locallang.xlf when one want to use just the key in an Extbase-based template (without giving the path and filename). All other files are referenced with an "absolute" path including the filename.

should the labels for the backend module also go in there or in locallang.xlf

A backend module translation is something special, the keys are hardcoded, so one have to name them mlang_labels_tablabel, etc. Maybe this has changed with v12 with the rework of the backend module registration, don't know yet.

It also depends on the extension author's needs. If many translations are the same for TCA and frontend, using locallang.xlf for both is a valid option. So, I would not state in the docs: you have to do is this way or that way or name your files with that name. I would not even make a recommendation about the naming.

Now, opinionated: As locallang_ as prefix is superfluous (it is already in a folder named Language, so the purpose is clear) I name my XLF files, for example, Database.xlf instead of locallang_db.xlf or BackendModule.xlf for backend module translations, ExtensionConfiguration.xlf for extension configuration or Form.xlf for form-related translations. This is a much cleaner approach than the historically burdened locallang prefix.

[sypets]

@brotkrueml Thanks, for answering.

What do you propose to do now? (I would have to check if a change is necessary to document the minimal standards (locallang.xlf and mlang_labels_tablabel (?)).

It has been a while I looked at it. I can't give a good answer right now, I would have to take some time to think it through.

It also depends on the extension author's needs. If many translations are the same for TCA and frontend, using locallang.xlf for both is a valid option.

agree.

So, I would not state in the docs: you have to do is this way or that way or name your files with that name.

Only for the stuff where it would be necessary. locallang.xlf and the content mlang_labels_tablabel (?) etc.

Now, opinionated: As locallang_ as prefix is superfluous ...

Agree (somewhat). But, if that is changed, would have to be decided and implemented in core first, I think. Then also changed in various places (documentation, extension_builder), so it is quite a task. It would be a recommendation, not a hard rule, but it would be nice if it were done sticking to common conventions.

I would rather stick to the conventions in the core. If they are not good, try to change them there. But otherwise stick to them.

But, changing some things is a lot of effort, so sometimes it is best to leave it.

I contribute to core and extensions and things being done differently set me off (though in the case of the language file, I don't think I would really care that much).

My personal opinion: doing things differently (naming of directories, files etc.) is cognitive load and can be distracting. We have conventions elsewhere, so where conventions / rules are helpful (and can be found hopefully without endless discussions), I would try to document them and stick to them.

[brotkrueml]

Agree (somewhat). But, if that is changed, would have to be decided and implemented in core first, I think. Then also changed in various places (documentation, extension_builder), so it is quite a task. It would be a recommendation, not a hard rule, but it would be nice if it were done sticking to common conventions.

Then we have to communicate that to the Core team. As this would be a breaking change (extension authors may rely on the XLF files) it would be a candidate for v13 (so after branching of v12). But I don't think it is worth the work. It works for now and the benefit is low.

My personal opinion: doing things differently (naming of directories, files etc.) is cognitive load and can be distracting. We have conventions elsewhere, so where conventions / rules are helpful (and can be found hopefully without endless discussions), I would try to document them and stick to them.

So, we can document a recommendation which one can follow or not - with a hint that the Core does is otherwise by now (for historical reasons).

[Alagts]

No action since many years.