Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

(plus) New suggested key

(thumbs down) Key suggested for deprecation

(tick) old key which is consistent and does't require changes

(question) To be discussed

Apps

(plus) "apps.test-app.label", (philip+, espen+)
(thumbs down) "test-app.app.label", //we currently add for every key which ends with label automatically another key without label suffix. This unnecessary increases number of keys in memory. We should always specify if it's label/description/icon from my point of view. Adding the label suffix is not a big deal.
(thumbs down) "test-app.app"

App launcher group

(plus) "appLauncherLayout.groups.groupName.label", //you can immediately identify in an i18n file that it's a group name (compared to the old keys below), moreover appLauncherLayout is the name of the app launcher configuration node

(mika+-, topher+-, philip+-, espen-)

(thumbs down) "app-launcher.groupName.label",
(thumbs down) "app-launcher.groupName"

Actionbar

Sections

 //new suggested keys respect the path in configuration:

(plus) "apps.test-app.subApps.test-subapp.actionbar.sections.test-section.label",

(plus) "subApps.test-subapp.actionbar.sections.test-section.label", 

(plus) "actionbar.sections.test-section.label", 

vs

(thumbs down) "test-app.test-subapp.actionbar.sections.test-section.label", 

(thumbs down) "test-app.test-subapp.actionbar.test-section.label", 
(thumbs down) "test-app.actionbar.sections.test-section.label",
(thumbs down) "test-app.actionbar.test-section.label",

//having the same key with/wo label suffix unnecessary increases number of keys in memory:

(thumbs down) "test-app.test-subapp.actionbar.sections.test-section",  

(thumbs down) "test-app.test-subapp.actionbar.test-section", 

(thumbs down) "test-app.actionbar.sections.test-section", 
(thumbs down) "test-app.actionbar.test-section"

Actions

New suggested keys:

(plus) "apps.myapp.subApps.browser.actions.myaction.label",
(plus) "subApps.browser.actions.myaction.label",

(tick) "actions.myaction.label",

Currently supported keys:

(question) "myapp.browser.actions.myaction.label", //short key, doesn't respect configuration path but is shorter

 //having the same key with/wo label suffix unnecessary increases number of keys in memory:
(thumbs down) "myapp.browser.actions.myaction",
(thumbs down) "actions.myaction"

Columns

New suggested keys:

(question) "apps.<app>.subApps.<subapp>.workbench.contentViews.<view-name>.columns.<column-name>.label",
(question) "subApps.<subapp>.workbench.contentViews.<view-name>.columns.<column-name>.label",
(question) "workbench.contentViews.<view-name>.columns.<column-name>.label",

(tick) "columns.<column-name>.label",  //we could probably support this one, if no objections

vs currently supported keys:

(question) "<app>.<subapp>.views.<column-name>.label",

(question) "<app>.views.<view-type>.<column-name>.label",

(question) "<app>.<subapp>.views.<view-type>.<column-name>.label",

(question) "<app>.views.<column-name>.label",

(question) "views.<view-type>.<column-name>.label",

(question) "views.<column-name>.label",

Pretty hard to remember, isn't it? (big grin) Also notice <view-type>. This is tree/list and it doesn't matter how is the view called in config although all the other parts are always the node names in JCR (yaml). 

//having the same keys with/wo label suffix unnecessary increases number of keys in memory:

(thumbs down) "<app>.<subapp>.views.<view-type>.<column-name>",

(thumbs down) "<app>.<subapp>.views.<column-name>",

(thumbs down) "<app>.views.<view-type>.<column-name>",

(thumbs down) "<app>.views.<column-name>",

(thumbs down) "views.<view-type>.<column-name>",
(thumbs down) "views.<column-name>"

Forms

Dialog

New suggested keys:

(plus) "test-module.dialogs.testFolder.testDialog.label",
(plus) "dialogs.testFolder.testDialog.label", //this is "must have". We currently cannot use module-independent translations

(question) "dialogs.testDialog.label",

//currently supported keys:
(thumbs down) "test-module.testFolder.testDialog.label",
(thumbs down) "test-module.testFolder.testDialog" //having the same keys with/wo label suffix unnecessary increases number of keys in memory

Tabs

New suggested keys:

(plus) "test-module.dialogs.testFolder.testDialog.form.tabs.testTab.label",
(plus) "dialogs.testFolder.testDialog.form.tabs.testTab.label",
(plus) "form.tabs.testTab.label",

//currently supported keys:
(question) "test-module.testFolder.testDialog.testTab.label", Do we still want to have this one? It's shorter but not a big difference and it doesn't respect configuration path.
(thumbs down) "test-module.testFolder.testDialog.testTab",  //having the same keys with/wo label suffix unnecessary increases number of keys in memory
(thumbs down) "testTab.label", //That's pretty dangerous since it's too short and without a type prefix. How you can possibly know where it belongs by looking in the translation file? Is it for template/dialog/app?
(thumbs down) "testTab"

Fields

New suggested keys:

(plus) "test-module.dialogs.testFolder.testDialog.form.tabs.testTab.fields.mgnl-testField.label",
(question) "dialogs.testFolder.testDialog.form.tabs.testTab.fields.mgnl-testField.label",
(question) "form.tabs.testTab.fields.mgnl-testField.label",

(tick) "fields.mgnl-testField.label" //we might want to have generic translation for all fields with this name (fallback)

//currently supported keys:
(question) "test-module.testFolder.testDialog.testTab.mgnl-testField.label", //vs "test-module.dialogs.testFolder.testDialog.form.tabs.testTab.fields.mgnl-testField.label",

(question) "test-module.testFolder.testDialog.mgnl-testField.label",

(question) "testDialog.testTab.mgnl-testField.label",

(question) "testTab.mgnl-testField.label", //vs "form.tabs.testTab.fields.mgnl-testField.label",

(question) "testDialog.mgnl-testField.label",

//having the same keys with/wo label suffix unnecessary increases number of keys in memory:

(thumbs down) "test-module.testFolder.testDialog.testTab.mgnl-testField",

(thumbs down) "test-module.testFolder.testDialog.mgnl-testField",

(thumbs down) "testDialog.testTab.mgnl-testField",

(thumbs down) "testDialog.mgnl-testField",

(thumbs down) "testTab.mgnl-testField",

Validators

New suggested keys:

(tick) <parentFieldI18nKey>validators.emailValidator.errorMessage //respects configuration path

(tick) validators.emailValidator.errorMessage //respects configuration path

//currently supported keys:

(thumbs down) <parentFieldI18nKey>validation.errorMessage //no information about validator, just field definition

 

 

  • No labels