In the current response coming from the i18n JSON files, we noticed that there's a mixture of frequently changing data (eg. [mastheadNav], [footerMenu], etc) and text used for interfaces (eg. [misc], [leaving], [localeSelector], etc).
The purpose of this feature request issue is to evaluate the current data structure used for the Masthead and figure out a way to streamline the management of the frequent change content (eg. Masthead & Footer menus) vs text content used interfaces.
This is becoming more relevant as AEM is looking to build its own version of the Masthead datastore/endpoint that will be used to deliver content to the Carbon Masthead both for the Global/Standard, Cloud, and other products that are adopting the <dds-masthead-container> and <dds-cloud-masthead-container> components.
Treating everything as interface text
The current solution treats everything as interface text. This causes the problem that frequently changing data (or content data) will require awkward processes and workflows in GitHub by the editorial team.
Treating everything as content
This assumes that content data like the text and urls of the links lives together with text coupled to the interface (for instance the word Search in the search box). This has the problem that interface/design changes in the component will require editorial changes that must happen in sync with the release of component.
The solution
Identify interface text data that can be extracted from the i18n data structure.
House the management and translation for the interface text data within the Carbon for ibm.com project or a package if it's applicable.
Note: This is just our initial thought, however, we're open to suggestions.
Application/website
AEM, Drupal
Business priority
Medium Priority = upcoming release but is not pressing
What time frame would this ideally be needed by (if applicable)
The timeframe of this work has not been determined yet. We just like to put this request on the board and figure out the solution and resourcing at a later time.
Examples
Example of data/text used for interfaces.
"misc": {
"backtotop": "Back to top",
"cancelText": "Cancel",
"close": "Close",
"cookiePrefs": "Cookie preferences",
"continueText": "Continue",
"editProfile": "Edit profile",
"emailThisPage": "E-mail this page",
"feedback": "Feedback",
"mpScopedSearh": "Products",
"withinMp": "Products",
"next": "Next",
"noresults": "No results found",
"prev": "Previous",
"resultsNav": "Use down and up arrow keys to navigate through the results.",
"search": "Search",
"selectCountry": "Select a country/region",
"sharePage": "Share this page",
"signin": "Sign in",
"signout": "Sign out",
"sitenav": "Site navigation",
"welcomeback": "Welcome back"
}
The problem
[mastheadNav]
,[footerMenu]
, etc) and text used for interfaces (eg.[misc]
,[leaving]
,[localeSelector]
, etc).<dds-masthead-container>
and<dds-cloud-masthead-container>
components.Treating everything as interface text
The current solution treats everything as interface text. This causes the problem that frequently changing data (or content data) will require awkward processes and workflows in GitHub by the editorial team.
Treating everything as content
This assumes that content data like the text and urls of the links lives together with text coupled to the interface (for instance the word Search in the search box). This has the problem that interface/design changes in the component will require editorial changes that must happen in sync with the release of component.
The solution
Note: This is just our initial thought, however, we're open to suggestions.
Application/website
AEM, Drupal
Business priority
Medium Priority = upcoming release but is not pressing
What time frame would this ideally be needed by (if applicable)
Examples
Example of data/text used for interfaces.
Code of Conduct