Deduplicate data, use this repo as PrestaShop dependency

[mvorisek]

Citing from README:

Once a Pull Request has been accepted in this repository, changes should be synchronized to the main project's "localization" directory via Pull Request.

Embedding the localization files in the project allows users to benefit from localization files without having to download them.

What is the advantage of this repo, can we drop it in favor of "main project" to deduplicate the data?

[matks]

Hello @mvorisek this repository contains the latest version of our Localization files. These files are available through a PrestaShop webservice and can be downloaded by users from the BO.

We also copy this data regularly inside main https://github.com/prestashop/prestashop repository to provide a quick way built-in for users to have a starting base of files that can be used. But this base is frozen: people who download PrestaShop 1.7.4.4 today install shop with the built-in localisation files of 2018 (1.7.4.4 was released in 2018).

So this repository is the latest version of localization files and this is the content being distributed while the data in the main repository is a snapshot of this data at a given time, which is useful but not 100% necessary.

We need to keep both.

For the people who install 1.7.4.4 today: when they install the shop they use outdated localisation files but they can get the latest up-to-date files when they download the pack from Back Office.

[mvorisek]

Why not simply require this package via composer in https://github.com/prestashop/prestashop?

[matks]

What would be the benefit of turning this into a Composer package? We would still need to submit a PR to update the main repository data. Today PR contains the diff in XML files, tomorrow it would be a composer.lock line change.

Also I feel weird about using a PHP package manager to manage a full XML repo 😅 . With version numbers and so. It could work but I'm not sure if it's a common practice.

[mvorisek]

We would still need to submit a PR to update the main repository data

that is not true with semantic versioning :)

Also I feel weird about using a PHP package manager to manage a full XML repo

no worries about this :)

[matks]

The current process that states how the localisation files are managed, between this repository and the main repository, seems to fit the project needs. I don't understand why it it would be an issue to have duplicate data between this repository and the main repository, provided it is very clear which data is the source of truth and which data is a copy frozen in time.

I don't see major benefit in changing the process 🤔 to use Composer.

[mvorisek]

Is it better to change a version number or copy data from one location to another? I do not see a major reason to not use a composer 😄

[matks]

Is it better to change a version number or copy data from one location to another

It means you decide of a release strategy and a versioning strategy.

I do not see a major reason to not use a composer 😄

I do not see a major reason to use it either 😉 . We do not do things "because we dont see a reason NOT to do it". We do things when we see a clear benefit doing them.