Refactor internationalization to use translation keys instead of inline translations

[yibeichan]

@claude reformatted @alistairewj's feedback as the following

Problem Description

The current internationalization approach requires including all language translations directly in the schema, which creates several maintenance challenges:

1. Version Control Noise: Every translation fix or update requires modifying the entire schema
2. Maintenance Burden: Translation updates are coupled with schema updates, making it difficult to manage translations independently
3. File Size: Schema files become unnecessarily large with multiple language variants

Current Approach

{
  "question": {
    "en": "What is your age?",
    "es": "¿Cuál es tu edad?",
    "fr": "Quel est votre âge?"
  }
}

Proposed Solution

Adopt a key-based approach similar to ARB (Application Resource Bundle) format used in app development:

• Schema stores translation keys instead of actual text
• Separate translation files maintain the actual text for each language
• This aligns with reproschema's existing pattern of referencing activities

Benefits

• Separation of Concerns: Translation updates independent of schema changes
• Better Version Control: Clean diffs for translation vs. structural changes
• Scalability: Easier to add new languages without modifying core schema
• Familiar Pattern: Similar to how activities are already referenced in reproschema

Drawbacks

• Readability: Schema becomes less human-readable (keys instead of questions)
• Complexity: Additional logic needed to resolve translations
• Tooling: Requires translation resolution in all implementations

Proposed Implementation

Schema file:

{
  "question": "@age_question"
}

Translation file (en.json):

{
  "age_question": "What is your age?"
}

Translation file (es.json):

{
  "age_question": "¿Cuál es tu edad?"
}

Action Items

• Design the translation key format and naming conventions
• Specify the translation file structure and location conventions
• Create a migration strategy for existing multilingual schemas
• Update the reproschema specification to support translation keys
• Implement reference resolution logic in reproschema-py
• Update reproschema-ui to handle translation loading and resolution
• Provide tooling to validate translation completeness
• Create documentation and examples for the new approach
• Consider backward compatibility requirements

Questions for Discussion

• Should we support both inline translations and key-based translations?
• What should be the standard format for translation files (JSON, YAML, ARB)?
• How should we handle missing translations?
• Should translation keys be namespaced by activity/protocol?

[satra]

This was an explicit decision we took that a state of the schema changes when a translation (or any component of it) is modified (added/updated/deleted). This is based on the notion that reproschema schemas can be pointed to using the github file resolution (or other such resolver) and need to be persistent. It cannot ever provide a surprise to any consumer. We recommend anyone using a schema to point to a specific committish in all aspects of their deployment. if this principle of no surprise can be supported through a separation, we can include it.

however, reproschema does allow certain separations (see the country item here: https://github.com/ReproNim/reproschema-library/blob/2f8b6d54ef59406dfe797c1f03fd695f9f16e7aa/activities/demographics_and_background_information_v1/items/country_of_birth#L18

(it should be adjusted though to reflect a local committish based reference - i.e. should not have a master based url link).