This is a work document to help identifying common patterns in i18n keys, with the aim of rationalizing the set of generated keys.
Dynamic parts vs. static (keywords) parts
Primary vs. secondary
Disambiguation
my-app.my-subapp.actionbar.sections.my-section.label
my-app.my-subapp.actionbar.sections.my-section
my-app.my-subapp.actionbar.my-section.label
my-app.my-subapp.actionbar.my-section
my-subapp.actionbar.sections.my-section.label
my-subapp.actionbar.sections.my-section
my-subapp.actionbar.my-section.label
my-subapp.actionbar.my-section
Respect JCR path vs. parent keys?
DefinitionMetadata#getName vs. DefinitionMetadata#getRelativePath
Identify parts to assemble:
- root-definition, pick from module, deftype, relative path, and name
- 8 potential keys
module.deftype.relative.path.name
module.relative.path.name
deftype.relative.path.name
relative.path.name
module.deftype.name
module.name
deftype.name
name
- 8 potential keys
- "internal path"
form.tabs.tabMain.fields.firstName.validators
- suffix
- bean property name
- one overrules them all?
Rationalize number of keys
- Deprecate/suppress .label-suffixed keys?
Keep extremes or most differentiated?
Super specific vs. super short
module based vs. deftype based
Root definitions vs. unrooted definitions
- TemplateDefinition, DialogDefinition
- vs. TabDefinition, ActionbarSectionDefinition
- Reusable definitions within different roots
Specialization & Pluralization
content-app.browser.actionbar.default = {0,choice,1#Item|1< Items}
my-app.my-subapp.actionbar.my-section = {0,choice,1#Fruit|1< Fruits}
TranslationService vs. SimpleTranslator vs. MessageFormat
Provide the most generic level
email validator has no default translation