Greater text control for double byte languages

[areagan1030]

The problem

The AEM team has been receiving feedback from our APAC authoring teams that there ongoing concern with headline type size and translated text, specifically with double byte languages (Chinese, Japanese, Korean). AEM components often use the Carbon 10 $expressive-heading-05 token for content section headlines, which we are hearing is often resulting in text that wraps to too many lines when translated.

The AEM docs site includes character guidance for most text elements across components, though it is ultimately the author's responsibility to use headlines that balance accurate communication with visual consistency.

This issue is also raised on the AEM development team's Jira board: ADCMS-4132

The solution

In relation to headlines, double byte page owners and authors are requesting the ability for slightly reduced type sizes to be available for expressive type tokens, as applied across AEM components using Carbon style tokens.

This has been called out as relating to: leadspace titles, content section titles, and headlines on card elements.

Application/website

Carbon for AEM

Business priority

Medium Priority = upcoming release but is not pressing

What time frame would this ideally be needed by (if applicable)

TBD

Examples

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate issues

[oliviaflory]

Thank you @areagan1030 for opening this issue and providing examples!

1. The type scales we are all using are all inherited from IDL and Carbon packages
2. There is a proposal from the brand team to scale non-latin languages to either 90% or 95% across all the type tokens
   a. I think these values were chosen to avoid the potential for overlap with the varying characters
3. I think scaling everything as a whole would make the most sense to ensure that the type scales and hierarchy remains the same throughout vs opening up controls within the components.

Here are a few examples from @DianaStanciulescu's explorations:

Arabic + Latin

Japanese + Korean + Latin

[areagan1030]

This is great — this seems like a perfect point to also loop in @andy-blum. Andy, I'm thinking this is something we might want to look at wrapping in to our AEM/CIBM planning notes.

[oliviaflory]

Just to note: if the proposal goes through, I think the scaling would be applied at the Carbon type package level, so C4IBM and then AEM in turn would inherit it automatically (at least that is my assumption?)

[andy-blum]

@oliviaflory That would be my assumption as well, though would this change be in Carbon 10 or only in v11?

[oliviaflory]

That's a great question @andy-blum, I will chat with the devs about how that would work implementation wise.

In the meantime would @areagan1030 be able to text those use cases you shared and see if 95 or 90% reduction in scale would solve the issue to satisfy your authors?