Problem
Assuming the personal and business name abbreviation work has landed, Worldwide::Names.abbreviated and Worldwide::BusinessNames.abbreviated support script specific abbreviation rules for Latin, Han, Hangul, Hiragana, Katakana, and Thai names.
Worldwide::Scripts.identify also recognizes the Arabic script, but neither abbreviation API defines an Arabic rule. Arabic script input therefore returns nil, causing callers to fall back to the greeting or full business name. This is safe, but it leaves Arabic script names without the abbreviated display available for other supported scripts.
Goal
Define culturally appropriate Arabic script abbreviation rules and implement them consistently for:
- Personal names through
Worldwide::Names.abbreviated(given:, surname:, ideal_max_length:)
- Business names through
Worldwide::BusinessNames.abbreviated(name:, ideal_max_length:)
The rules should be reviewed by someone with relevant Arabic language and naming expertise before implementation. They should not assume that Latin initial or acronym conventions transfer directly to Arabic.
Questions to resolve
- For personal names, should an abbreviation use the first grapheme cluster of the given name and surname, preserve one component in full, or follow another convention?
- How should common particles and name components such as
ال, آل, عبد, أبو, and بن affect abbreviation?
- For business names, should multiple words form an acronym? If so, how should the definite article
ال, conjunction و, and other short components be treated?
\p{Arabic} covers languages beyond Arabic, including Persian and Urdu. Can one script based rule serve all of them, or should unsupported cases continue returning nil until the API can distinguish language or locale?
- Should the output contain only source text in logical order, leaving bidirectional rendering to callers, or are directional controls ever required?
- How should
ideal_max_length apply to each rule?
Acceptance criteria
Context
This follows the initial abbreviation APIs added to Worldwide::Names and Worldwide::BusinessNames. Those ports intentionally preserved existing shopify-i18n behavior, where recognized but unhandled scripts return nil. Arabic support was deferred so that its rules could be designed explicitly rather than inferred from another script's conventions.
Problem
Assuming the personal and business name abbreviation work has landed,
Worldwide::Names.abbreviatedandWorldwide::BusinessNames.abbreviatedsupport script specific abbreviation rules for Latin, Han, Hangul, Hiragana, Katakana, and Thai names.Worldwide::Scripts.identifyalso recognizes the Arabic script, but neither abbreviation API defines an Arabic rule. Arabic script input therefore returnsnil, causing callers to fall back to the greeting or full business name. This is safe, but it leaves Arabic script names without the abbreviated display available for other supported scripts.Goal
Define culturally appropriate Arabic script abbreviation rules and implement them consistently for:
Worldwide::Names.abbreviated(given:, surname:, ideal_max_length:)Worldwide::BusinessNames.abbreviated(name:, ideal_max_length:)The rules should be reviewed by someone with relevant Arabic language and naming expertise before implementation. They should not assume that Latin initial or acronym conventions transfer directly to Arabic.
Questions to resolve
ال,آل,عبد,أبو, andبنaffect abbreviation?ال, conjunctionو, and other short components be treated?\p{Arabic}covers languages beyond Arabic, including Persian and Urdu. Can one script based rule serve all of them, or should unsupported cases continue returningniluntil the API can distinguish language or locale?ideal_max_lengthapply to each rule?Acceptance criteria
Worldwide::Names.abbreviatedhandles supported Arabic script personal names according to the approved rule.Worldwide::BusinessNames.abbreviatedhandles supported Arabic script business names according to the approved rule.nilso callers retain their existing fallback behavior.Worldwide::Scripts.identifyand operates on grapheme clusters rather than bytes or codepoints.ideal_max_length, and mixed or unsupported scripts.nilfallback.Context
This follows the initial abbreviation APIs added to
Worldwide::NamesandWorldwide::BusinessNames. Those ports intentionally preserved existingshopify-i18nbehavior, where recognized but unhandled scripts returnnil. Arabic support was deferred so that its rules could be designed explicitly rather than inferred from another script's conventions.