Make i18n messages (preamble of posted conversation) configurable

[0ndifined]

As an admin, I want to be a able to edit the preamble of the posted conversation (such as "Ich habe eine passende Konversation gefunden:" or "Das hab ich dazu in gefunden") in a free text field at the Admin interface.

For example, I want to be able to show no preamble in front of the posted conversation or customize the message myself.

[ruKurz]

This configuration should be a client and query builder specific setting.
@westei Is there anything keeping us away to include this into the scope of 0.7.1?

[westei]

The WIdget gets such configurations as i18n (@Peym4n please add an example).

I do not want to have such split up in various query builder configurations. IMO it is better to add a separate section for such data to the client configuration and implement an own web service that allows the widget to retrieve this part of the configuration.

This would allow to customise also other parts of the widget

WDYT?

[Peym4n]

Currently these localized preambles are used in the widget:

"widget.conversation.answer.title": {
    "de":"Ich habe eine passende Konversation gefunden:",
    "en":"I found a similar conversation:"
},
"widget.conversation.answer.title_msg": {
    "de":"Ich habe eine passende Nachricht gefunden:",
    "en":"I found a related message:"
},
"widget.latch.answer.title": {
    "de": "Das hab ich dazu in $[1] gefunden:",
    "en": "Here is what I found in $[1]:"
}

[ruKurz]

For the time being we could change the texts to an empty String. But how can we customize the standard texts without changing the standard distribution? In my opinion, labels etc. should be configurable.

[westei]

If we want them to be configureable by client we need to use the Smarti ConfigurationService and add a Webservice that allows the Widget to get the client specific widget i18n configuration. If so we should create an according issue.

The system wide defaults should be configured as typical for i18n (I am sure @mrsimpson and @Peym4n know how this is usually done)

[ruKurz]

Why do we need to create another issue? The title of this issue exactly matches our needs. I will rename it into a more generic description.

[ruKurz]

The implementation effects Smarti code only (Webservice + Widget) there is no general Rocket.Chat adoption required.

[westei]

• Smarti Admin UI (to add a new section for (widget config)
• Samrti Webservice to provide this config
• Smarti Widget: needs to check for the client specific i18n config

[mrsimpson]

Why should we make this configurable per client? I expect a system wide configuration to be sufficient. @Peym4n is it already possible to configure the widget‘s i18n without building it?

[ruKurz]

@mrsimpson configure i18n is currently done in the JavaScript of the Smarti Widget. See @Peym4n comment above (#227 (comment)).

[Peym4n]

@mrsimpson currently the i18n data exists as json in the code.
I will separate it from the rest of the code and put it in an i18n.json file.

[mrsimpson]

@Peym4n having it in a separate file will still make it necessary to compile a new Smarti version. Unless it can be injected from the consumer to the widget (e. G. via the constructor or via a session variable), I’d not consider it „configurable“

[Peym4n]

@mrsimpson I'm aware of that. I just wanted the i18n strings to be separate. I wasn't proposing a solution. If anyone has a solution to make these strings configurable across the system I would be happy to implement it.
It would be possible to pass the data to the constructor of the widget and read it there. The question is then, how would they be configured on the Rocket.Chat side and where can they be loaded from.

[westei]

What to we try to accomplish here?

• Is it sufficient to configure it in the i18n file part of the Smarti Widget. This will be releated to Smarti versions
• As @Peym4n noted one could add a feature that allows to parse i18n when constructing the WIdget. As far as I understand this would allow to manage this in Rocket.Chat
• If their is the need to have those things client specific I would suggest to add those to the Client Configuration and let the widget retrieve it from Smarti (also on initialization)

I think we need a decision what we are aiming for.

[Peym4n]

@mrsimpson The configurable i18n JSON can now be set in the smartiOptions object as i18n.
This JSON will then extend and overwrite the existing hardcoded JSON.