Changing phrases/messages in the locale CSV files but not in the PHP files.

[addison74]

Over time, when there were issues with the translations, it was decided to keep the initial form of the phrase/message in the PHP files, and its modification was done only in the CSV files. I personally do not agree with this solution, but because the opinions expressed by the majority were that those who use OM in languages other than English should not be affected, I respected it.

However, let's not leave this issue only half solved. When there are different phrases on the same row in the local CSV files, this mention should be made in the PHP code with a standard comment before that phrase/message. For example, /* This is not the correct text and it is changed in CSV file*/.

This way it will help us to learn about that there is an issue related to that phrase/message and that it has been solved in the CSV file. Here I had a discussion after which I closed the PR #1927 and another one was proposed that does not fix the phrases in the controller.

What should be done? We have to identify the phrases that are different in a row in all the locale CSV files, then found the PHP files that contain them and added that standard comment.

[addison74]

I checked all the local CSV files and I found only the following rows where there are differences between the columns.

Column 1	Column 2	CSV File	PR Change	PHP File
Password must be at least of %d characters.	Password must be at least %d characters.	Mage_Adminhtml.csv:719	PR 1456	/app/code/core/Mage/Admin/Model/User.php:608
				/app/code/core/Mage/Adminhtml/Block/Customer/Edit/Tab/Account.php:168,221
				/app/code/core/Mage/Adminhtml/Block/Permissions/Tab/Useredit.php:92,115
				/app/code/core/Mage/Adminhtml/Block/Permissions/User/Edit/Tab/Main.php:103,123
				/app/code/core/Mage/Adminhtml/Block/System/Account/Edit/Form.php:94
				/app/design/adminhtml/default/openmage/template/resetforgottenpassword.phtml:51
				/app/design/install/default/default/template/install/create_admin.phtml:74
. Do not use event" for an attribute code	it is a reserved keyword."	Mage_Eav.csv: 33	-	NO REFERENCE
The alert subscription has been deleted.	You will no longer receive price alerts for this product.	Mage_ProductAlert.csv:24	PR 1930	app/code/core/Mage/ProductAlert/controllers/UnsubscribeController.php:72
The product is not found.	The product was not found.	Mage_ProductAlert.csv:26	PR 1930	app/code/core/Mage/ProductAlert/controllers/UnsubscribeController.php:57

There is a row that has no correspondence in any file in the repository and if it is confirmed it must be deleted.

For the other rows, if you don't want to modify the CSV files we must establish the standard comment and then add it to those PHP/PHTML files.

[justinbeaty]

I see both sides. Breaking translation packs isn't great, but I also like things to match in CSV files. My opinion should be taken at less value because I only use English.

However, we could add in another mode to #2332 where it could map the first column when we change them.

So for example, it can find / replace any instance of The product is not found. in any non en_US files. This would allow us to change the CSV and also create an easy way for store owner to fix their translation files.

[addison74]

As you may see, there are only a few rows found in the CSV files in which column 1 differs from column 2. Modifying them to be the same I don't think it would create big issues. The one in ProductAlert is a issue for the programmer, if he reads the code he will see that the messages are provided incorrectly. It was fixed by changing the displayed phrase in Frontend.

We are now analyzing what is in these locale files, but I have never had the problem of whether there are phrases in the PHP/PHTML files that have no correspondence in the CSV files.

[fballiano]

As a personal preference (and not English mothertongue) I'd prefer not to break the language packs since it may not be easy for the store owners to recognise one sentence suddenly became untranslated in their store, and it looks really ugly and unprofessional.

That said I also see the point of view of developers, maybe if we had a repo with all the language packs and we kinda try to maintain them... then it wouldn't be an issue after all...

[justinbeaty]

I put some thoughts over here: #2332 (comment)

In the end I'm not really bothered by non-matching CSV. But if we can provide help for the store owner with the translations.php shell script for each upgrade then maybe we can break it.

Because on each upgrade the user should need to run php -f translations.php -- missing anyway. Otherwise they may miss new strings we've added in the release.

[addison74]

I have to agree with you because I manage stores where translations are used. Every time we introduced new strings I had to manually edit those locale CSV files to keep them up with the updates. This is really an issue, to introduce strings and they are not translated by the store admin.