Lately we are several users of version 1.7 of Prestashop to have realized that it was no longer possible to translate a product sheet in the backoffice if we disabled a language.
Of course, this was reported by users of the official PrestaShop forum that I invite you to consult when you have a question about the use of this CMS for online business.
For the older ones, this behavior is totally new, the previous versions of PrestaShop, like the very good 1.6, used to simply disable a language so that it is no longer available in the language selector of the Frontoffice part while leaving us free to continue to translate our products for any new language in the backoffice.
With its 1.7 version, PrestaShop decided to rely on a robust and recognized framework using Symfony.
The choice was made to gradually integrate this new framework into the aging architecture of the code, which had evolved over the years, accumulating certain pitfalls.
Recently, the section related to the processing of product sheets was integrated into this new framework.
This new structure has highlighted this regression between the old versions and the new one, which has embarrassed many users.
Analysis of possible solutions
So I set out to analyze the code for this new page based on feedback from the Github of Prestashop.
Seeing that the solution of this problem would not be treated quickly and that in any case it would not be retroactive on already released versions of PrestaShop 1.7, I peeled the code to discover where the wolf is hiding.
It appears that Prestashop has taken the old function to list the languages, omitting in passing that this function returns natively only the languages that are active on the store.
Thus, it is logical that when a language is deactivated, it is no longer active on the modification of product files.
So, I first tried to list all the files concerning this product sheet to correct the call of this function in order to return all the installed languages, including the disabled ones.
Things I managed to do.
Except that I must have missed some files, because during my test, that I made of course on the last version of PrestaShop available to date, the 184.108.40.206, in multi store mode to be sure of the most extreme case of data processing, I found myself, following the recording of my changes with a nice error message.
This simply means that the entire data processing chain must be traced back to the time of registration in order to be sure that the processing is done on all the installed languages and not just the active ones.
This work requires a lot of time and I admit that I don't have enough to do everything.
So I decided to simplify things and create a new module to get around this limitation.
The solution: the module
So I started to use PrestaShop's native language selector to modify two or three lines of code in order to avoid this problem, but it wasn't that easy because I had to propose a way to disable the languages in order to not display them while keeping them active in the backoffice.
So I decided to turn this into a new module that replaces the default language selection module.
This new module, when installed, will automatically uninstall the default module, and gives you the possibility to disable the display of the languages you want on the frontoffice and thus prevent your customers from visiting the site in a degraded version since you still have to do all the translations.
The result is not extraordinary visually since we stay on the same design as the original module, but we get exactly what we wanted to correct this defect.
Download the module