Announcing updates in locale files (Mage_[...].csv)?

[addison74]

Every time there were changes in the OpenMage code that concerned phrases in English, changes were made only regarding the translation of the phrase in the local CSV file, not in the source code. Let's say that I agreed with this matter, the number was not very large, I think I counted about 6. The problem appears when you want to add phrases. These require mandatory translations.

That's why I propose that from now on there should be a post, a README, whatever you want, that informs what changes are made to the translation files (deleted, added, modified). On this occasion, changes can be made in the code, I can also make changes in the Backend. I don't like to see that in the local English files I have different phrases.

I hope that in this way we will solve an issue that always had an argument "we don't want to change the existing local files".

[fballiano]

I think we should use an online translation platform, I see many FLOSS projects on https://crowdin.com/page/customer-testimonials which as a free plan for open source projects: https://crowdin.com/page/open-source-project-setup-request

After creating the project we should be able to import all the CSVs, from this repo but also all of the translation packs from https://github.com/orgs/OpenMageModuleFostering/repositories?q=locale and go from there.

[sreichel]

OpenMageModuleFostering is not good to start with. Its just a backup of Magento-connect and a lot of modules there have not been updated for i while, but got new releases at github/packagist.

Better search for well maintained (till 1.9.4.5) locale packs first and maybe list them somewhere. E.g.

DE: https://github.com/riconeitzel/German_LocalePack_de_DE
Others: https://github.com/search?q=magento+locale+pack (MaWoScha)

@addison74 imho ... if we change strings in phpfiles, we should add them - instead of replacing them in CSV. Maybe you remember, i'd added some CSV files for OM-translations. So it was easy to install a locale pack and add another CSV for OM-translations ...

I dont want to maintain different locale packs ...

[fballiano]

also if we don't replace them, changing/removing them from templates/core has the same effect, the "old" strings won't be used anywhere. also there's no need to maintain language packs, crowdin does everything.

ps: good tip about the better maintained language packs, thanks!

[addison74]

My opinion is that a phrase that wants to be updated by deletion or change should be kept in the CSV file because an extension could use it. There are quite a few extensions that have Magento module dependencies and that use already created phrases. I agree that in the case of changing an existing phrase, the new one should be added and not modified. Here comes to help us this file that I propose to be created in OpenMage root.

[addison74]

I think my post was misunderstood. I proposed that all changes related to locale files be announced "somewhere" so that each OpenMage user can find out what they are and make the translations themselves.

For example, in a PR I added to the Mage_X.csv file the following phrase that appears in the Backend "Please enable this feature for protecting the form". As an English speaker, I don't have to do anything, but if Backend is translated into Italian, German, then this phrase must be translated. Here comes to lend a helping hand this place where the changes are announced.. Based on them, I go and edit the files and update my translations.

In this way, both the situation of an added phrase and a modified one is solved. Concretely, when a new version is launched we should make a post about these phrases as well. We do not maintain the translation files, only the list of changes. For example, added/changed/....

This place can be mentioned in the README file.

[fballiano]

I understood what you mean, but using a platform like crowdin there's no need to mention anything anywhere, we setup an automatic import of the CSVs and the platform knows what strings are translated or not and show everybody the strings that need to be translated.

[addison74]

Unfortunately I have no experience with Crowdin.

[fballiano]

me neither but a lot of projects use that (or similar), like opencart for example:
https://crowdin.com/project/opencart
everybody can contribute and we can for sure have it for free.

I'll try to setup a demo

[sreichel]

I think my post was misunderstood. I proposed that all changes related to locale files be announced "somewhere" so that each OpenMage user can find out what they are and make the translations themselves.

We already had a working, non-breaking change for locale packs, but that got removed with #1621. Only purpose of these files was to add new translatable strings and changed ones into a separate file to make change more clear. You have could used a locale pack and had only to translate the LTS-files ...

[addison74]

I would suggest creating in OM root a file called TRANSLATIONS.md or LOCALE.md. In this file will be found all updates of phrases made in PRs starting from that moment. The OM version, the PR number, the phrase, the type of modification (U - update / D-delete / A-add) will be mentioned. In this way, it is easily observable and anyone can become aware of updates based on which they can do their own translations in CSV files.

If you agree, we must establish the format of the file and I will take care of its content. From that moment I will analyze each merged PR and if it contains phrase updates then I will mention them in this file.

[tmotyl]

my 2c.

1. potentially breaking changes should be communicated. Putting them in the readme is the least we can do.
2. we could have a "compatibility module" which would provide things we have removed from 20.0, so people who want upgrade step by step can install the module and have old stuff working (like mysql4 classes), and after refactoring they can remove the module
3. It's more a dream, but Rector can do automatic refactorings like this. If we have rules to migrate code from old version to new one automatically, we could just ask people to run rector to find out changes and fix them immediately.
4. using crowding for managing translations and allowing external contributors is a good idea. In TYPO3 world we also use crowding to translate core and community plugins.

[justinbeaty]

With #2332 we can list strings that haven't been translated. So, a store owner can run that each release to see what is left for them to translate. The only problem is that we have a backlog of strings that haven't yet been added to the csv files and many unused ones. Once that's cleaned up, it would be easy to identify strings.

[addison74]

I haven't tested that PR, many thanks for the suggestion. Maybe we should mention it in README.md.