A Software Product Line may use the same words in an API response, panel button, and public site. If each part defines its own translation for the same meaning, wording drifts and every new locale requires repeated work. Reusable translation keys belong at the broadest scope where their meaning remains the same. The challenge is to share genuine common language without forcing domain-specific terms into a vague global dictionary.
Search before adding a key
Before creating a new label, look through development, API, panel, site, and part localization resources for an existing term with the same meaning. A generic action such as “Copy” or “Done” should not be recreated for every domain. A word like “Author” may belong in a part if it has a distinct editorial meaning, while a general “Step” may belong in the development core even if one feature uses it first. Reuse is about meaning, not identical English spelling. Two words can look alike in English and need different translations in another language.
Place the key by audience
A key shared across API, panel, and site should live in a common localization scope. A panel-only action can live in panel core or the relevant part's panel localization. A blog-specific visitor label belongs in the blog site scope unless other processes use it. This hierarchy lets a translator find the owner and prevents a leaf part from importing another part's private strings. When a key becomes useful more broadly, move it and update callers rather than leaving duplicate definitions. Preserve one authoritative translation for each meaning.
Give translators context
Short keys can be ambiguous. “Open” might mean a verb, a status, or a business that is operating now. Key names and nearby context should express the intended meaning. Use complete messages with placeholders rather than concatenating fragments whose word order varies by language. For counts, use proper plural forms. Keep variables named for what they represent so a translator can understand the sentence. A shared key should be stable enough that changing its source wording does not unexpectedly alter unrelated product flows.
Validate every supported locale
A new or moved key should be present in all supported locale files, with a defined fallback policy where translation is temporarily incomplete. Automated checks can detect missing keys, invalid placeholders, and duplicate definitions. They cannot judge whether the wording is natural or consistent, so human review remains useful for important workflows. Test the string in context, including long translations and right-to-left layout. A key that fits a short English button may overflow elsewhere, which is a component design problem as well as a translation task.
Avoid overgeneralizing
Not every “Save” has the same user expectation. Saving a draft and finalizing a payment may need distinct phrases and different error messages. Keep domain-specific terms with the part that owns them when their meaning differs. A global dictionary with many subtly different variants becomes hard to navigate; a part dictionary full of generic actions creates duplication. Review repeated strings periodically and move only proven shared meanings. The right scope is the one that minimizes drift without erasing useful context.
Maintain the workflow
When a feature changes, update its labels, tooltips, validation messages, emails, and help content together. Provide translators with screenshots or usage notes for ambiguous terms. Use shared keys so one correction benefits every process that expresses the same idea. For SMB products serving many locales, this discipline reduces cost and improves consistency. The goal is a localization system that lets parts remain independent while customers hear one coherent product voice. Assign a clear reviewer for shared wording changes, since a small edit can affect several products. Keep a simple record of where each shared key appears so reviewers can see its impact before changing the translation.