Reusing translations

[tsteckenborn]

I noticed that the same description and text might still result in two different translation keys. To me it's currently unclear how to best reuse translations. Should you always default to enums once you've got the first sort of duplication?

[cpojer]

Tools like Crowdin can automatically handle such cases and merge them. However, I have since disabled this in Athena Crisis so that each string is confirmed separately. I noticed that despite the same description and text, the context might be different and require a different translation in other languages.

[kayhadrin]

@tsteckenborn:
With regards to your mentioning fbt enums in the OP:
As engineers, it's very tempting to try to reuse them (programmatically) but that's when you can easily shoot yourself in the foot and end up producing inaccurate/incorrect translations on the UI.

Do you have any example of redundant-looking fbt strings where you think that translations should be recycled?

[kayhadrin]

Hum, sorry, I'm really not sure what you have in mind... Some sample and/or some UI mock up would help clarify this. 😅

[tsteckenborn]

Let's take for example (the start selling with parts):

(https://tailwindui.com/components/marketing/sections/pricing)

Basically my question revolved around the case that if I'd define it with the same description and text it appears three times. As Christoph explained that might be wanted though, as it can't be guaranteed that it's the same context and just by chance both are the same.

[kayhadrin]

Thanks for providing a UI mock up!
Based on what I see:

1. Some sentences like "{localizedPrice} per month" or "Start a free trial" can easily be written as fbt strings - as long as you provide clear & exhaustive descriptions. (E.g. "Plan monthly price, where localizedPrice could be a text like $19")
2. The "Start selling with:" followed by a list of text items is a common fbt scenario where you'd need to provide good descriptions - not only for the "Start selling with:" preamble, but also for each text item like ("Custom domains").
   E.g.
   Text: "Custom domains"
   Desc: "Plan feature name, shown as part of a bullet list that reads like: 'Start selling with: {planFeatureName}'"
   It's very important to include the context in which the feature name appears, so that translators can properly apply relevant grammatical rules. This also means that this list of feature plan names is not necessarily reusable in other UI contexts (since the surrounding text may be different). That's what Christopher was referring to in his previous comment.

[tsteckenborn]

😅 I need to better phrase what I try to say. My question related to the fact, that there are repetitions across all three plans in the sample above. This - at least in my test - resulted in thee entries with the same text and description. Contrary to that other tooling I used beforehand "deduplicated" identical keys. But as far as I understood Christophs reply above that's wanted and you'd rather rely on external tooling to deduplicate (such as Crowdin).

Indirectly my impression out of these is that here the reliance on other software / solutions (such as crowdin) and expectation of potential translators not being the developers is higher compared to other ones such as i18next. @cpojer I think that was also indirectly indicated by my questions on how I would even translate it (which was not really explained in the first draft of the readme). Here some other solutions are currently more straightforward (not necessarily better) and have more tooling support for simpler use cases (just looking eg for the terms i18next and extensions such as https://marketplace.visualstudio.com/items?itemName=Lokalise.i18n-ally)

[kayhadrin]

Oh ok, so if I understand correctly, you're seeing multiple strings with the same hash (i.e. same text and description) in the collected strings json? I suppose they just have different source file/line/column location info. If that's the case, then it's working as expected because the fbt collect script doesn't deduplicate them.