Ob 7109 add support for informal language fix #106
Conversation
…-language-fix' into OB-7109-add-support-for-informal-language-fix
| private String fetchDefaultTranslations(String translationComponentName, String languageCode, Dialect dialect) { | ||
| String translationFilename = getTranslationFilename( | ||
| translationComponentName + "." + languageCode | ||
| + TranlationMangementServiceApiClient.getDialectSuffix(dialect)); |
There was a problem hiding this comment.
Shouldn't this fallback to mailservice.de.json? Or how does it work when its using dialect but we have no translation catalog for dialect stored in project?
In frontend there is a logic for fallback because not everything needs to be translated in dialect so we only dialect stuff in dialect catalog and all other translations are taken from the de catalog. Maybe we need a merge of them here too?
There was a problem hiding this comment.
For the weblate api call it should be fine but we need to check if the configuration is correct. It should automatically fill up non translated strings in dialect with fallback to de.
There was a problem hiding this comment.
hi @web-mi , do you want to have fallback logic to DE in case there is informal language setting in consultant profile but no informal file found? Ok, we can build this.
But I am against merging of json files. IMO if informal dialect can be set we should have all keys translated to dialect -> this should be required configuration.
Otherwise some keys will have formal, another informal translations which will lead to a mix-up between Sie/Ihr and Du/Dir forms in the applications.
So in worst case in one email user will get mixed up form. Either informal lang is fully supported and therefore all keys are translated, or not and in this case we don't need to have separate informal json file.
There was a problem hiding this comment.
Yes fallback logic if file does not exists locally. What is happening now when there is no informal file?
In Frontend we have 2700 lines inside de.json and only some of them have informal Translation. Thats why we have the fallback to de.
For example if we have a email subject "New message from advice seeker" its not required to translate it to informal because there is no formal language in this sentence.
There was a problem hiding this comment.
hey @web-mi , added the fallback logic in case informal translation file does not exist
There was a problem hiding this comment.
Oh dear, Marc has touched on an nice topic here. In the context of the mail service, I would be fine to have all translations duplicated and adapted where needed. That's how it would currently work, because it's a new component in Weblate.
However, with the many keys in the frontend, Marc's merge is of course important. Well, as I understand it, the frontend handles this itself, but of course it would be nice if all translation variants worked identically.
Do we need to have a chat about this?
There was a problem hiding this comment.
For frontend it makes sense to build a merge logic, but I don't see added value for the mailservice. Frontend translations are huge and there are would be many repetitions with duplicated keys.
For mailservice we have small amount of labels, files are small and this will not change, therefore treating dialect as separate lang and having all keys translated there is not a problem. We avoid the need to have merge logic that has to be tested and maintained in future. Building merge logic would IMO unnecessarily increase the complexity of the project.
I am always for consistency, but at the same time we need to avoid complexity which is already too big. Since we have microservice architecture, so we have also some freedom to decide on a service level. So we don't need to have force apply FE solutions if it does not fit to the given microservice.
There was a problem hiding this comment.
I was also speaking more from the perspective of the user operating Weblate... because they now need to understand how it works and where
There was a problem hiding this comment.
hey @tkuzynow, I think I started to have a look and again forgot to submit the review, stupido haha
For now it's just a typo but I think we should think about Marc's comment.
| @@ -13,6 +14,8 @@ | |||
| @Component | |||
| public class ThymeleafHelper { | |||
|
|
|||
| private static final String INFORMAL_GERMAL_LANGUAGE_TAG = "de-DE-u-va-posix"; | |||
| private String fetchDefaultTranslations(String translationComponentName, String languageCode, Dialect dialect) { | ||
| String translationFilename = getTranslationFilename( | ||
| translationComponentName + "." + languageCode | ||
| + TranlationMangementServiceApiClient.getDialectSuffix(dialect)); |
There was a problem hiding this comment.
Oh dear, Marc has touched on an nice topic here. In the context of the mail service, I would be fine to have all translations duplicated and adapted where needed. That's how it would currently work, because it's a new component in Weblate.
However, with the many keys in the frontend, Marc's merge is of course important. Well, as I understand it, the frontend handles this itself, but of course it would be nice if all translation variants worked identically.
Do we need to have a chat about this?
There was a problem hiding this comment.
hey @tkuzynow, I had a look and I think (and as it blocks) we can merge this.
Patric
|
Fixes #
Proposed Changes