No internationalization of Livechat-texts

[mrsimpson]

Description:

In the livechat-widget, texts are partly not translated although the translation is available in the source.

You can also see that the user's language is properly detected. Texts which are also available in the rocketchat-i18n-package are properly translated, such as Type_your_message

Server Setup Information:

• Version of Rocket.Chat Server: 0.58.1

Steps to Reproduce:

• Check out github.com/assistify/Rocket.Chat/tree/master/ (I am not sure that the texts are already merged into the current develop @ RC
• Open a new livechat and check the translations

[mrsimpson]

@sampaiodiego I experienced in the past that i18n in my custom packages are also not effective: I had to move them to rocketchat-i18n

[sampaiodiego]

@mrsimpson the point is that the "livechat mini-app" is completely separated meteor app. his source code is inside rocket.chat package, but it is not part of rocket.chat itself.

so for translations on "livechat mini-app", his own translations strings..

what happens sometimes (please see #8263 and #8267 - both affected our production build) is that you need to meteor reset the "livechat mini-app" so translations will be processed again.

so, please try going into packages/rocketchat-livechat/app folder and running meteor reset, then test again if the translations are not there.

[mrsimpson]

@sampaiodiego I tried a local build, meteor reset in packages/rocketchat-livechat/app as well as in the root (i've seen that in the travis configuration). No change.
Any other advice, a flag I need to set or similar?

[icosamuel]

I'm experiencing the same issue when translating the plugin according to the host-page's locale. These are the only texts I can't manage to get to work with Tapi18n.

[icosamuel]

After some investigating, I found that the translation behavior is inconsistent
In this example, only the Yes button is translated even though they all have the same underlying mechanism.

packages/rocketchat-livechat/app/client/views/options.js

text: t('Are_you_sure_do_you_want_end_this_chat'),
confirmButtonText: t('Yes'),
cancelButtonText: t('No'),

packages/rocketchat-livechat/app/i18n/fr.i18n.json

"Are_you_sure_do_you_want_end_this_chat": "Êtes-vous sûr de vouloir mettre fin à cette conversation ?",
"Yes": "Oui",
"No": "Non",

[mrsimpson]

@sampaiodiego I just debugged the widget and noticed, that by the time the options menu is getting created, the TAPi18n.getLanguage() returns the default one ("en"). Once the chat is loaded, it returns the proper client language.
I've also seen that the language is set in a method-call-callback in Template.livechatWindow.onCreated. I assume that the rendering of the options menu happens before the callback has completed and is not reactively re-triggered.

Edit: Well, the sequence does not seem to be the issue.
Even when wrapping the options.html in a check for Livechat.isReady();, the getLanguage will still return "en". TAPi18n seems not to immediately set the language once setLanguage is called:

[sampaiodiego]

@mrsimpson from what @renatobecker discovered, seems like the livechat widget uses i18n files of rocket.chat app. he opened this PR #9966 , could you give it a look?

[mrsimpson]

@sampaiodiego @renatobecker basically merged all the translations into the translations of the main app. While I believe this works, it's a bit ... strange to me. However, I also noticed that translations added in other packages than rocketchat-i18n (which aren't micro-apps like the livechat) are disrespected. I also had to move our translation files into the rocketchat-package. I however did not merge them, which works fine and at least keeps some things in order.

So if giving up the i18n-files in the livechat-app itself is your solution, I can of course live with that.

[sampaiodiego]

unfortunately the way we build and serve the livechat-app, makes tapi18n package request translations to the main rocket.chat app.. we couldn't find a way to change the request path though, so that's why we move all livechat translation to rocketchat-i18n.

if we had it as a different app/process running, it should work as expected.

[mrsimpson]

@sampaiodiego yup, understood. I still don't know whether the TAPi18n-package is a blessing or a curse, but the configuration definitely is the latter.
@renatobecker just fyi: You don't have to merge the files, see assistify@3340357 : A separate file in rocketchat-i18n/i18n also provides the translations. You could copy the files from the livechat-package during build just in case you want to serve the livechat as a separate app at some later point in time.
However, I assume you don't want to separate them again :-P

[renatobecker-zz]

@mrsimpson, I tried to load the livechat translation files during the Package.onUse (rocketchat-livechat/package.js), the same way it is done in rocketchat-i18n, but it just didn't work well.
So, because of this, we decided to unify the translation files inside rocket.chat package.

[mrsimpson]

@renatobecker I tried the same and many hours of my life reconfiguring TAPi18n. Without any success. I was hoping you had ad better connection to the Javascript library world ;)
Now, I can only imagine to get it solved with a meteor build pluginor by simply adding the file-copy to the build process (in the CircleCI-build-chain)

[sampaiodiego]

@mrsimpson I've also spent many hours of my life today fighting against TAPi18n package.

the solution I've found was similar to what you said, but I did on Rocket.Chat build itself, check it out

this will let everybody with duplicated files on filesystem, but they ignored by git, they will probably don't even notice.

what do you guys think on this implementation?

[mrsimpson]

@sampaiodiego I believe that's good enough!
Compared to just including it in the build, your solution also loads the i18n when launching locally via meteor run.
I believe adding a README in the i18n-package about the specialties might help, wdyt?

This package contains internationalization for Rocket.Chat.
Due to limitations of the i18n-library used, only translations from this very folder will be respected.
Thus, if you extend Rocket.Chat with custom packages which have got own translation files, you'll have to put them into this package. They should be named <package>.<language>.i18n.(json/yaml).

Alternatively, you can add the the i18n-files in your package and then copy it to this folder during build time. In this case, you should add the copied files to the .gitignore. See the package.json for a sample how this is done for the livechat-package.

[sampaiodiego]

that might help. =)

[graywolf336]

Good news it that Rocket.Chat Apps makes usage of the i18n package's runtime configuration of languages. However, this is only on Rocket.Chat side and not on the LiveChat side since the Apps don't touch anything related to the LiveChat. Just thought I'd share since it has worked fine as far as I can tell from the current uses.

Rocket.Chat/packages/rocketchat-apps/client/orchestrator.js

Lines 27 to 41 in a9aea36

	_loadLanguages() {
	RocketChat.API.get('apps/languages').then((info) => {
	info.apps.forEach((rlInfo) => this.parseAndLoadLanguages(rlInfo.languages));
	});
	}
	parseAndLoadLanguages(languages) {
	Object.keys(languages).forEach((key) => {
	try {
	TAPi18next.addResourceBundle(key, 'project', languages[key]);
	} catch (e) {
	// Failed to parse the json
	}
	});
	}

[AndreVolpi]

Hello, is there a PR or a plan to make it so the translations on the LiveChat are actually used?

I took a quick look at the source code and it looks to me like it should at least be getting the language from the browser, but for our installation (purelly installing the docker container) the Livehcat is always in english and never uses any other language (no matter the application language or the browser language or any other thing).

[sampaiodiego]

Now that the old/legacy livechat widget is gone, this issue doesn't apply anymore.

If you have new suggestions or additions to the new livechat widget, please refer to https://github.com/RocketChat/Rocket.Chat.Livechat

[vineethvijay-MyT]

@AndreVolpi Did you got this fixed? We are facing the same issue.

[AndreVolpi]

@AndreVolpi Did you got this fixed? We are facing the same issue.

No, we gave up on it as a company. (also having the chat didn't give a positive impact on our website so didn't make sense)