Feature-request: When adding new keys, check if target language already has manual translation

[axelcedercreutz]

Issue: Currently, when creating new strings and having the ability to translate them manually (e.g. people being bi-lingual / some specific naming conventions etc.), there's no way of committing the new strings and the manually translated strings without the GH Action for generation overriding the manually created strings. Same goes for edits where you edit the source and a target at the same time.

Expected behavior:

1. I create / edit a source string
2. I make the same edits to 1/5 of our target strings.
3. The Lingo.dev's github action is able to understand, that for the 1 target language, the create & edit has been done manually, so it won't touch it. For the rest 4 languages, the translations are created.

[mathio]

I dont think we are able to determine if the translation was done manually or if it is an outdated translation.

I'd suggest to only keep target locales you want to manage via Lingo.dev in your i18n.json config.

[axelcedercreutz]

Hey,

Thanks for the reply @mathio ! However, the case is not that we wouldn't want to have those tracked by Lingo.dev, it's just that in some cases we know e.g. a certain naming should be something in one of the target languages, which then is annoying to first have to generate the translations locally with the "wrong" translation and then correcting it separately, instead of just writing the ones we know that we want to have. This is especially in the case when we have new strings (that have pre-determined naming conventions) an issue.

[mathio]

Thank you for your reply. I believe you can use our Glossary to set known translations. You can even upload translation memory (TMX) and CSV files if you have a lot of data. Does that make sense for your use case?

[maxprilutskiy]

OK i think i see what you mean here @axelcedercreutz :

1. when a new entry is added
2. simultaneously in the source AND some target file(s)
3. then the target value gets replaced when CLI runs

it happens because it can't find lockfile entry for that source entry, so it thinks it's new, so it does full localization across all the languages

Suggested design:

• Before running translations, we'll run a step that'll look for new keys and add lockfile entries for them first, so that during the diffing step CLI translates only the languages that are missing.

This will be addded to the new run command (we're deprecating the i18n soon).

I'd love us to ship this!

[axelcedercreutz]

Oh damn, sorry for not replying 🙈 didn't for some reason get any notifications about the replies and forgot about it...

Before running translations, we'll run a step that'll look for new keys and add lockfile entries for them first, so that during the diffing step CLI translates only the languages that are missing.

@maxprilutskiy you got it exactly right, if you could get a run command for this working that would be helluva awesome 🙌