Feature Request: Update default values in repository

[paulwer]

Hi folks,
I like to share an idea, which may have some great benefits exspecialy for the devs and when looking at the code, when not deployed / hosted localy.

The idea was to have an additional option, which enabled the tolgee cli to update the default values within the t and T components.
And also to have an additional property to overwrite the existing translations based on the current default value.

This would enable developers to tight the relation between code and tolgee platform even more and would improve DX, exspecialy in smaller teams.

[JanCizmar]

Hey! Can you please describe, what you is your process of creating new keys, when you develop your app from developer perspective?

E.g. In Tolgee we do it like this.

1. We add the key into the code without the default value. t('welcome.message')
2. We open the app and alt+click the new, untranslated key
3. We translate it and so it's saved to the Tolgee Platform

We don't use the default values, because then it's unsure, what is the actual source of truth.

[paulwer]

Hi Jan,
in our case the developer will design the page and will use default-values within the programm-code.
After release to our dev env, the tolgee keys get created within the tolgee platform and translators are informed to do their checks on the automatic translated keys.

When all translation keys are checked, the feature gets released/activated on prod within the new release.

[JanCizmar]

Have you considered to use the approach whe developers add keys to Tolgee?

It has multiple benefits.

1. The context is extracted, so you can get reliable results from Tolgee Translator
2. Screenshots can be created, so humen translators have the context
3. You have single source of truth, which is Tolgee Platform.

[cyyynthia]

Adding my two cents on the dev side from my plugin proof of concepts (that I wish I had more time to put into!):

• In the PoC default strings are mandatory, as a way to ensure all strings have a text associated with them
• The default strings from source are considered a separate "placeholder locale" and would be overridden by strings from the platform. If the strings are unavailable (no internet, restricted access, string deleted, ...) then the placeholder is used.

Rationale for giving priority to strings from the platform is to give the translation team the final say to what the string should be instead of developers, so the translators can update the tone, for instance.

It should be noted the mentioned PoC "breaks" the standard flow and the concept is very experimental/draft. Most notably, it makes the assumption that no locale file will live alongside the code: they are pulled from the platform at build time which is not the common case (generally, files do exist within the project. choice to ditch them is to keep strings closer to the code to make it less awkward to add, test and remove strings from the editor, but again is a very novel/experimental/untried approach).

An existing open question about this architecture is how to handle conflicting default strings in the source code, although this is not something that is within the scope of this issue 😅

[paulwer]

@JanCizmar regarding your process. clicking on the key within the app does not work in all cases. sometimes f.ex. its used as a placeholder for an input field or any other thing, which is not clickable. in such cases this string has to be manualy find within the tolgee-app and be changed there.

Our workflow, and why we are using the placeholders is, that the developer can define the key and contents localy and change it as often as they like and they are then imported, with automatic translations, when he/she runs tolgee sync. this gives us more flexibilty within the development cycle (localy).

Our wish for a system would be to use the default value as a first start to import it into tolgee platform and remove the default-value automaticly, when the key exists in the platform. On the other hand we would like to have a preview within the editor of the current actual value of the tolgee key.

Maybe this can be achieved with an combination of the mentioned thing (removing default values after generation) and having a vs-code plugin to preview the current value. f.ex. like other do with icon libraries => the visualy replace the content in this case with the icon until its clicked. then its editable.