Javascript text not getting translated to other languages

[skashish]

Preconditions

1. Magento CE 2.1.7
2. Php 7.0 Mysql 5.5
3. Ubuntu 14.04

Steps to reproduce

1. Install Persian language pack as mentioned here.
2. Set Persian locale in Admin panel.
3. Inserted the following line

"Minimum length of this field must be equal or greater than %1 symbols. Leading and trailing spaces will be ignored.","ﺡﺩﺎﻘﻟ ﻁﻮﻟ ﺍیﻥ ﻑیﻝﺫ ﺏﺍیﺲﺗی ﻢﺳﺍﻭی ﻭ یﺍ ﺏﺯﺭگﺕﺭ ﺍﺯ %1.ﻑﺎﺼﻠﻫ ﻩﺍ ﺩﺭ ﻦﻇﺭ گﺮﻔﺘﻫ ﻦﺧﻭﺎﻫﺩ ﺵﺩ.",module,Magento_Ui

inside

vendor/mageplaza/magento-2-persian-language-pack/fa_IR.csv

4. Ran the following commands

bin/magento cache:flush
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy fa_IR
bin/magento indexer:reindex

Expected result

The javascript text on User registration page ( on password field ), must be translated to Persian.

Actual result

The javascript text is still seen in English.

[hostep]

This will most likely be fixed by #10747, which should be released in one of the next Magento 2.1.x releases (probably 2.1.10?)

[skashish]

@hostep Is there some quick fix for this till the time it gets resolved?

[hostep]

@skashish: we use https://github.com/cweagans/composer-patches/ to apply custom build patches on top of Magento 2 source code, but it's a bit of a tricky library to work with, takes a bit time getting used to how it works...

@tkotosz wrote a nice little tutorial over here about how you can use it: #10507 (comment) (we do it differently, but his way should work as well)

[joachimVT]

I'm working on this ticket.

[jahvi]

I can have a look if that's ok, trying to do my part for #SQUASHTOBERFEST 🙂

[ishakhsuvarov]

Hi @jahvi
Please accept the github team invitation (in email or GitHub UI) so that we could assign this ticket to you. Thanks.

[hostep]

@magento-engcom-team, I believe the tag Reproduced on 2.2.x is incorrect here.

I just tested this on a 2.2.0 installation, installed the Persian language pack mentioned above, changed that one line, also installed a Dutch language pack, as a reference, setup 2 extra storeviews next to the default English one, both for Persian and Dutch, setup the correct locale's. Reindexed, flushed cache, removed my local storage cache, since translations can exist in there, and then test this out.

Both Persian and Dutch work perfectly fine.

So I am unable to reproduce this bug, see screenshot for proof:

Just wanted to make sure people aren't trying to fix bugs which aren't there anymore.

The bug still exists on Magento 2.1.x, but should be resolved with #10747 in 2.1.10 probably?

UPDATE: I didn't test this in production mode, but I'm assuming this won't change the outcome.

[jahvi]

That's strange I tested in 2.2 and the 2.2-dev branch and I was able to reproduce the issue in both, I tried with the Spanish translation and also the Persian translation mentioned above:

The main problem as far as I can see is that the string doesn't exist in the js-translation.json file so it doesn't get picked up by the translator function in JS so I don't think #10747 will help with this particular issue. Can you confirm if the string "Minimum length of this field must be equal or greater than %1 symbols. Leading and trailing spaces will be ignored." exists in your generated js-translation.json file?

[hostep]

@jahvi, yes the translation is in my pub/static/frontend/Magento/luma/fa_IR/js-translation.json file:

    ...
    "Minimum length of this field must be equal or greater than %1 symbols. Leading and trailing spaces will be ignored.": "ﺡﺩﺎﻘﻟ ﻁﻮﻟ ﺍیﻥ ﻑیﻝﺫ ﺏﺍیﺲﺗی ﻢﺳﺍﻭی ﻭ یﺍ ﺏﺯﺭگﺕﺭ ﺍﺯ %1.ﻑﺎﺼﻠﻫ ﻩﺍ ﺩﺭ ﻦﻇﺭ گﺮﻔﺘﻫ ﻦﺧﻭﺎﻫﺩ ﺵﺩ.",
    ...

Make sure you follow step 3 of @skashish's instructions, because by default that particular string hasn't been translated in the Persian language pack as of writing.
Also: make sure to clear out the local storage of your browser, at one point I had a wrong version of the translations in my local storage, by clearing my browser caches, and refreshing the page, I got it right.

If you can still reproduce the bug, would you be so kind to write out all the performed steps in detail, so I can try to reproduce it? Thanks!

UPDATE: just tested in production mode, to be absolutely sure, and still, the bug seems fixed over here. When testing production mode, make sure to specify only one locale for the setup:static-content:deploy command, because we still have that bug in 2.2.0 where you deploy multiple locale's at once, it generated the wrong translation file.

[jahvi]

I can confirm that this works for fa_IR translations after clearing cache and generated files now, however I'm getting a strange issue for the es_AR translation.

I installed following the same instructions but I noticed it didn't work even after adding the translated string in the es_AR.csv file, I then noticed that this language pack includes a es_ES.csv file as well so I went ahead and updated the string there which worked this time but I wonder if this is expected? I would asume that if the locale is set to es_AR then Magento would just use that translation not es_ES or am I missing something?

Steps to reproduce

1. On latest 2.2-dev branch, install es_AR translations.
2. Select "Spanish (Argentina)" as Locale.
3. Update the "Minimum length of this field must be equal or greater than %1 symbols. Leading and trailing spaces will be ignored." string in the es_AR.csv file in vendor/mageplaza/magento2-spanish-language-pack.
4. Clear cache, generated files and local storage.
5. Go to customer registration page and try to set a short password.

Just trying to figure out if this is still a bug.

[hostep]

@jahvi: as far as I remember correctly, if two or more .csv files are in one single language pack, magento bundles them together and treats them as one language pack. In the Spanish pack you are referring, there are two csv files. Since es_ES.csv comes alphabetically after es_AR.csv, I think the lines defined in es_ES win, so if you would only change the line in es_ES.csv it should probably work. I believe it's a mistake of that particular language pack to bundle it with two .csv files, one should be enough and won't cause this confusion.
It doesn't even matter how those csv files are called, they can be called file1.csv and files2.csv, it should have the same result.

@magento-engcom-team, @okorshenko: I believe it has been proven now that this issue is fixed in 2.2.0 and the tags Reproduced on 2.2.X, SQUASHTOBERFEST and 2.2-develop can be removed and replaced with 2.1-develop. And then the issue can be closed when PR #10747 is released in the next 2.1.x release.

[jahvi]

I understand, thanks for the clarification!