Skip to content

Add Arabic script rules for personal and business name abbreviation #551

Description

@trishrempel

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

  • The chosen personal and business name rules are documented, including examples and rationale.
  • The rules receive review from someone with relevant language and naming expertise.
  • Worldwide::Names.abbreviated handles supported Arabic script personal names according to the approved rule.
  • Worldwide::BusinessNames.abbreviated handles supported Arabic script business names according to the approved rule.
  • Unsupported or ambiguous Arabic script cases continue to return nil so callers retain their existing fallback behavior.
  • Implementation reuses Worldwide::Scripts.identify and operates on grapheme clusters rather than bytes or codepoints.
  • Tests cover blank components, one and multiple word names, combining marks, relevant particles, ideal_max_length, and mixed or unsupported scripts.
  • Tests cover any explicitly supported Arabic-derived languages, or document and verify their nil fallback.
  • README documentation includes Arabic personal and business name examples.

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions