tolgee
Propagate exact (or some high threshold) memory matches to other keys upon translation
Is your feature request related to a problem? Please describe. In our situation, we have the potential for many keys with duplicate source English. Since we are translating surveys, many questions will have answers like "Very much" or "A little". Or survey designers can solve this by referencing shared survey elements, but if they don't do that, our translators might be asked to translate "A little" multiple times.
We can't just only send distinct English because sometimes the English has different meaning based on context, for example "Fair" (a party/carnival) vs. "Fair" (somewhat agree/moderate).
Translation memory helps with this problem but it requires the translator to click through the duplicates and assign the match as the translation. We are looking for a feature that makes this more automated.
Describe the solution you'd like Say 3 duplicate (as far as source English) keys are uploaded to Tolgee. If the translator updates the translation on the first one, could Tolgee offer a checkbox that is checked by default (per project settings) that says "Also save this translation on key x and key y which have 100% match to the reference English". So it's "automatic" application of translation memory after the one of the keys is translated, not when the keys are created/imported.
Describe alternatives you've considered We can implement something like this today with a webhook and using the translation suggestion API, however, it would be ideal to have this be more native in the UI and more explicit (like a checkbox) instead of those translations propagating in the "background" via a webhook.
Additional context N/A
Hi! That's an interesting use case! ^^ Is there a specific reason for not combining these strings under one key? If they are truly the same and you want to update them together, using a single shared key seems like the best option. Is there a reason you prefer to keep them separate?
In our case, the same phrase may need contextualization based on the survey question. This is the example I gave above:
We can't just only send distinct English because sometimes the English has different meaning based on context, for example "Fair" (a party/carnival) vs. "Fair" (somewhat agree/moderate).
So we can't combine into one key called "fair" because the translator will need to customize based on the context. However, it's easier for them to spot check an auto-applied translation memory than it is to click though each individual translation and apply the top recommendation from memory.