Language support and localization planning

[needsofmany]

We are opening this discussion early so language support can be planned cleanly instead of bolted on later.

The first development focus remains import, readable preview, validation, profile management, and data safety. Even so, many of the most important messages in PluralBridge will eventually need careful translation:

• import results
• missing or degraded data warnings
• privacy and visibility language
• safety guidance
• recovery/export messages
• account and security text
• field labels and navigation

Our current thinking is to keep application text in a translation structure where each language can be translated and reviewed without requiring development knowledge. We have used this kind of approach before: stable text IDs, source language text, context notes, and one column or entry set per target language.

This discussion is for:

• language requests
• localization planning
• translation workflow ideas
• terminology concerns
• accessibility/readability concerns
• volunteer interest
• review process suggestions

We especially want to avoid losing good ideas while the app foundation is still being built. Translation may come later in implementation, but the planning can start now.

Please include the language, locale if relevant, and any terminology or cultural concerns that should be considered.