Clarify direction of Internationalization category

Background

There is currently some overlap and confusion between the responsibilities of the Import and Integrate group (which owns the Internationalization category) and the Localization team. The Import and Integrate group has not actively worked on the Internationalization category for at least 3 years due to other priorities and capacity constraints.

Internationalization vs. Localization

To clarify the general distinction between these functions:

Internationalization (i18n) is the technical foundation that makes a product adaptable to different languages and regions. This includes:

  • Separating text from code (externalization)
  • Handling pluralization rules across languages
  • Supporting various character encodings
  • Managing date, time, number formatting
  • Enabling bidirectional text support
  • Building technical infrastructure for translations

Localization (L10n) is the adaptation of the product to specific locales, which includes:

Current Issues

  1. Incomplete Internationalization Work: Despite the ownership by Import and Integrate, several technical internationalization foundations still need work:

  2. Overlap in Epics: Sub-epics under the Category:Internationalization Strategy epic overlap with Localization team work, including epics like "Localization," "New Languages," and "Improve Current Translations."

  3. Outdated Direction Page: The Category:Internationalization direction page is largely obsolete as it primarily discusses localization topics rather than technical internationalization concerns.

Proposed Solutions

Option 1: Transfer Category Ownership to Localization Team

Transfer ownership of the Internationalization category to the Localization team. This would be advantageous because:

  • One team would have full context and responsibility
  • The Localization team already handles related work
  • It eliminates the current situation where one owning team lacks capacity and context
  • It streamlines communication and decision-making

To support this transition, we should:

  • Add engineering resources to the Localization team to handle technical i18n requirements
  • Conduct knowledge transfer of any relevant information from Import and Integrate

Option 2: Create a Focused Engineering Task Force

If the Localization team cannot absorb the technical aspects:

  • Form a dedicated engineering task force to complete the outstanding technical internationalization work
  • Define clear scope, timeline, and deliverables
  • Ensure close collaboration with the Localization team
  • Once complete, transition maintenance to the Localization team

Option 3: Deprecate the Category

If suitable technical foundations exist and only maintenance is needed:

  • Deprecate the Category:Internationalization
  • Move essential remaining technical work to appropriate engineering teams
  • Remove the Category:Internationalization direction page
  • Update documentation to reflect new ownership model

Proposed Next Steps (could be done in preparation to choose one of the options above)

  1. Audit of Current State: Conduct a thorough audit of:
    • Current internationalization implementation status
    • Outstanding technical requirements
    • Review and close obsolete epics and issues under Category:Internationalization Strategy

Proposed DRIs: @wortschi and @opysaryuk

Those could be followed by:

  1. Automation Development: Prioritize automation of translation merging processes to reduce manual effort

This would need to refined and weighted.

  1. Documentation Update: Revise all relevant documentation to clarify ownership and processes

Questions for Discussion

  1. Can the Category:Internationalization be deprecated? If not, what specific technical foundations are missing?

  2. What specific engineering resources would be needed to complete the outstanding technical internationalization work?

  3. If the category cannot be deprecated, what is the best organizational structure to ensure both internationalization and localization work progresses effectively?

I welcome any alternative proposals or refinements to the options presented above.

Edited by Oleksandr Pysaryuk