Closed icosamuel closed 5 years ago
@sampaiodiego I want to start working on this, since it's a pretty big requirement for our support team. It would be very welcomed to have some pointers on what the best approach to solve this problem is.
I'm wondering how can the host-page initialize the livechat component with a localization/language parameter?
And for the User defined fields, I though about a "master drop down" that would reload the LiveChat tab in the admin panel for the selected language. Is it something to look forward to?
Thanks in advance, looking forward to hearing from you. Even small hints could be helpful!
I'm wondering how can the host-page initialize the livechat component with a localization/language parameter?
I think we can have an API for setting the language, something like:
RocketChat(function() {
this.setLanguage('pt-BR');
});
And for the User defined fields, I though about a "master drop down" that would reload the LiveChat tab in the admin panel for the selected language. Is it something to look forward to?
I think this is a good way for handling it.. currently we are saving this strings on the settings collection, which does not support i18n string.. I'm wondering if we should add support for i18n settings or should move this string into own livechat collection..
I don't know how we can integrate these configs into i18n, since they are defined by user at runtime and i18n uses built assets. I think its preferable to have them stored in a mongo collection, organized by localization, something like
{
'en-US' : {
'title' : 'LiveChat plugin',
'offlineMessage' : 'We are not online right now. Please leave us a message:'
},
'fr-CA' : {
'title' : 'Plugin de Chat Live',
'offlineMessage' : 'Nous ne sommes pas en ligne en ce moment. Veuillez laisser un message:'
},
[...]
}
and have them be instantiated only if the user defines them. What are your thought on this?
I also guess that TAPi18n.__('i18n_reference_key')
will be the solution for most constants like the Type your message
placeholder
I don't think we need TAPi18n
for translating this, since they are dynamic I think we should handle it ourselves.
so maybe creating another collection rocketchat_livechat_texts
, the object could looks like this:
{
_id: "RaNd0M",
lang: "en-US",
identifier: "offline-title",
text: "Livechat is currently offline"
}
client will always have all english texts, and when it needs another languages it can call a meteor method to get the all strings from the desired language.
livechat can have the same _
translation helper as rocket.chat so developing will be easy, but on livechat it will not rely on TAPi18n
.
I did the API part, and now I was into adding this parameter to getInitialData in order to do the translation part server-side
Meteor.call('livechat:getInitialData',
{
"token": visitor.getToken(),
"language": defaultAppLanguage()
},
and
Meteor.methods({
'livechat:getInitialData'(args) {
let visitorToken = args.token;
let clientLanguage = args.language;
I though about this since all the text variables are already passed through this method. Is it not appropriate?
I will look into creating a new collection like you said. Look to be an elegant solution!
Wanted to thank you again for your help :)
agreed, the language can be added to livechat:getInitialData
.. my concern is with uncompleted translations.. but maybe the ideal solution is to return english texts along with the ones requested by the client. this is not the easiest implementation but it is the most efficient data transfer wise.
and very very thank you for all your effort on contributing.
something like Livechat.title = chosenLanguage.title || en.title;
will do the trick to back up incomplete translations
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
Rocket.Chat Version: 0.58.2
For any business that operates in more than one language, it is a requirement that the LiveChat plugin be the same language as the host-page that would be independent from Rocketchat's server language config.
Things to have translations for:
User defined
RocketChat constants