Guidelines on descriptions?

[compojoom]

I'm wondering if anyone has guidelines on good descriptions for the fbt strings.

I realized lately that in our team we've used descriptions in the wrong way. We tried to be overly specific. For example if we have a logout button and this button appears on 3 screens we'll do:

"label logout on screen X"
"label logout on screen Y"
"label logout on screen XY"

I view this as problematic as translators now have to translate the same word with the same meaning 3 times.

Have you gyus adopted some kind of guideline on good "descriptions/context" for the strings.

For example - just do "label" when in a form and maybe provide some additional description if the label is ambiguous?

[jrwats]

If you'd like to ensure your translations and verbiage are the same across all your UI, fbt comes with the fbt.common API (fbt.c). fbt.c is a good choice when your strings are simple and the context across all uses is appropriate.

Anything more complicated, involving fbt constructs like fbt:param, fbt:plural, etc, will need different treatment. Most straightforward would be to simply "roll your own" and move any shared <fbt> instances to a shared utility module that others downstream can reference.

Lastly, you can always reuse the description (copy/paste) if you want to ensure you don't needlessly "overpay" for translations if you can guarantee the context doesn't change such that it deserves a different description.