Hello @Prestaworks ,

I reproduce the issue with PrestaShop version 8.1.x and Faceted search module v3.12.1 and v3.14.1, I'll add this to the backlog so it can be fixed.

Please be aware that some issues might take a very long time to be resolved. If this one is important to you and you cannot wait for it to be fixed on the project’s own time, we strongly suggest you consider contacting a professional to help you.

If you fix the issue on your end, please contribute it back to the project. Remember that the more people contribute, the better PrestaShop becomes for everyone.

Thank you

I can translate the labels just fine. The reference sort can't be translated because it doesn't discover it and it will be part of the language pack when 8.1.4 is released. This is a known limitation of the translation system.

ok, so the module can't be 100% translated for earlier versions than an unreleased version and that is fine? If so, go ahead and close the report and close the PR.

@Prestaworks Yeah, sucks, but that's how it is. It's the same situation with other strings and other modules. The same problem was with "Available" value in filters.

• First problem is that the translation system doesn't discover all new translations in some cases.
• Second problem is that XLF files for modules are distributed with the core, not the modules. So when you change something or add new strings, only the latest core version get the translation.

You can work around it quite easily, if you know:

• Insert the translation manually into ps_translations table.
• Delete var/cache/prod/translations folder.
• Voila, your translation is working.

Yeah I know, I can solve it, you too, but the average merchant can't :(

Maybe the best thing would be to redo the translations so there are no dividing between modules/front/BO and just all domains from all files are displayed in a big tree list. Would probobly be easier to find what you are looking for that way.

@Prestaworks Well, I try to convince somebody from the maintainer team for years to solve this, that it's an important flaw, but haven't been successful. 🤷‍♂️

I don't know the translation system well enough, but I'd guess the limitation is because the UX favors using the XLF default catalog because scanning aaaallll the code would be too long every time you need to translate something.

That said I agree with you that it's a pain that we can't edit wordings as long as the default catalog is not updated, maybe we could handle a systematic/automatic scan of all the files but then it should be cached. So the first init would take a while (potentially 1 or 2 minutes I'm not sure) but then you have it all. And when some new wordings are added you just need to clear the cache, but since new wordings are likely to come with update modules or update core these operations are already followed by a cache clear so it could work.

Sounds like a good way to handle it @jolelievre

@Hlavtox, it's something I want to improve. However, as you know @Hlavtox, there are many ideas and issues for a few project members. I'm considering whether it's worth investing in a dedicated search instead of loading all the data for specific translation.
I've identified two use cases from the merchants' translation needs:

• For a new project or module, I aim to translate the entire module or FO. In this scenario, the solution would be to display all or export/import all. Loading a large amount of data should not be an issue, but I would recommend importing it.
• For specific translation: I want to make changes to wording (because I forgot, or the current translation isn't suitable). In this case, it would only require searching across all domains directly without the need to navigate through domains, etc and load all the data and so on.

@MatShir I don't understand what you are saying. The solution is this:

• Core must discover translations in modules. It's a matter of ms, max single seconds. This will solve the issue with not being able to translate the strings that are not in the current XLF catalog.
• We must move XLFs to module repositories so they are distributed with the module not with the core. Core versions 1.7.8+ will work properly with them and load them. This will solve the issue of not having up-to-date XLF catalog after updating a module, because we update and distribute them with the core.

I made a little test on ps_newproducts module.

Translations in PHP file

$a = $this->trans('TESTPHP', [], 'Modules.Newproducts.Shop'); ✅ Translatable using module translations
$a = $this->trans('TESTPHP', [], 'Shop.Theme.Catalog'); 🔴 Not available, the discovery probably found this, but doesn't offer for translation.

Translation in /modules/ps_newproducts/views/templates/hook/ps_newproducts.tpl

{l s='TESTTPLMODULES' d='Modules.Newproducts.Shop'} ✅ Translatable using module translations
{l s='TESTTPLMODULES' d='Shop.Theme.Catalog'} 🔴 Not available, the discovery probably found this, but doesn't offer for translation.

Translation in /themes/classic/modules/ps_newproducts/views/templates/hook/ps_newproducts.tpl

{l s='TESTTPLTHEMEMODULES' d='Modules.Newproducts.Shop'} ✅ Translatable using theme translations
{l s='TESTTPLTHEMEMODULES' d='Shop.Theme.Catalog'} ✅ Translatable using theme translations