Fix JS translation search

[AntonEvers]

Description

• Add support for jQuery.mage.__('translate me') as well as $.mage.__('translate me')
• Add support for $.mage.__('Don\'t break on escape characters before \' or "')
• Add support for $.mage.__('Concatenating strings' + 'within a tranlation' + 'function')

Fixed Issues (if relevant)

1. JS Translation Regex leads to unexpected results and untranslatable strings #7403: JS Translation Regex leads to unexpected results and untranslatable strings
2. Translate messages on password strength #5509: Translate messages on password strength
3. js validation messages translation not working in customer account #5820: js validation messages translation not working in customer account
4. Some messages in Customer Account Create not translated #9967: Some messages in Customer Account Create not translated

Manual testing scenarios

1. See mentioned tickets for instances that could not be translated so far and translate them
2. Flush caches, clear browser storage, hard refresh and see translated strings

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds on Travis CI are green)

[ishakhsuvarov]

@ajpevers Would that still variables provided to the translation function? Would you like to implement some tests to verify these cases and keep those functional in the future?

[maaarghk]

I get an error on the core file i18n.js before and after this is merged, see the following -
https://regex101.com/r/AluQPA/1

[AntonEvers]

@maaarghk Good point. How on earth are we going to find out which strings will go into the original variable. It's hard to translate those properly at this moment...

[ishakhsuvarov]

@ajpevers @maaarghk I assume we have to find a solution to this case or revert the original fix. Do you have any ideas?

[AntonEvers]

@maaarghk If I read your comment right, the error happens before, as well as after this commit. So this PR has nothing to do with it, right?

@ishakhsuvarov As for finding JS translations in Javascript files using PHP, the way we currently look for translatable strings is not very robust. It only takes literal strings into account and the regular expressions used were (are?) not covering all instances of literal strings.

Apart from that, inline translations or any translation that is saved in the translation table is not taken into account with JS translations, because they are store bound and static file generation only knows languages and not store views.

In my opinion the only real solution is to revise the way js-translation.json is being compiled. Maybe a dynamic way that looks for translations once they are passed to the JS function and retrieves them from the php translation cache if they don't exist in js translation. This is just an idea, but optimising the current setup is not going to lead to a 100% working solution.