Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

AE: Sharjah sub-key has a shadda on the teh marbuta (إمارة الشارقةّ)

未关闭
  • 哪里不对？
#254 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
64/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
cpp
领域
localization

调研方向

Inspect the AE record and compare its sub_keys and sub_names with the live endpoint, then read region_data_builder.cc to see how the key and display name are consumed. Done means the Sharjah data no longer contains the misplaced mark, the key and name remain aligned, and the corrected record is reflected by the endpoint.

由索引模型根据 Issue 内容生成。

描述

In the AE (United Arab Emirates) data, the sub-key for Sharjah carries an ARABIC SHADDA (U+0651) on a letter that cannot take one.

Fetched from the live endpoint just now:

https://chromium-i18n.appspot.com/ssl-aggregate-address/data/AE
  -> https://www.gstatic.com/chrome/autofill/libaddressinput/chromium-i18n/ssl-aggregate-address/data/AE

"sub_keys":  "أبو ظبي~إمارة الشارقةّ~الفجيرة~ام القيوين~إمارة دبيّ~إمارة رأس الخيمة~عجمان",
"sub_names": "أبو ظبي~الشارقة~الفجيرة~ام القيوين~دبي~رأس الخيمة~عجمان",
The problem

The Sharjah key ends ... U+0642 U+0629 U+0651, i.e. a shadda placed after the teh marbuta ة:

key   إمارة الشارقةّ    U+0625 U+0645 U+0627 U+0631 U+0629 U+0020
                        U+0627 U+0644 U+0634 U+0627 U+0631 U+0642 U+0629 U+0651
name  الشارقة           U+0627 U+0644 U+0634 U+0627 U+0631 U+0642 U+0629

A shadda marks gemination of a consonant. Teh marbuta is a word-final letter representing the feminine ending, and it is not geminated in this name — it cannot carry a shadda. In الشارقة the gemination is on the sheen ش, by sun-letter assimilation after the definite article ال. If the name is written with the shadda at all, the correct position is:

الشّارقة    U+0627 U+0644 U+0634 U+0651 U+0627 U+0631 U+0642 U+0629
                          ^ shadda on the sheen

This is also what the standard romanization "Ash Shāriqah" reflects — the doubled Sh.

Why I think it is a slip rather than a convention

The same file spells Dubai's shadda correctly: إمارة دبيّ, where the final yaa genuinely is geminated (دُبَيّ). So the data can and does place a shadda correctly one field away. Sharjah is the odd one out, not the result of a consistent policy.

User-visible effect

name is the clean الشارقة while key carries the mark, and in region_data_builder.cc the sub-region is added as AddSubRegion(key, name). So a dropdown displays الشارقة while the value that is stored and printed on the label is إمارة الشارقةّ. The user cannot see the anomaly in order to correct it.

It also means the natural spelling does not validate — an address submitting الشارقة or إمارة الشارقة does not match the key.

Two smaller things in the same record
  1. The إمارة ("Emirate of") prefix is applied to only 3 of the 7 keys — Sharjah, Dubai and Ras al Khaimah have it; Abu Dhabi, Fujairah, Umm Al Quwain and Ajman do not.
  2. ام القيوين is missing the hamza; the usual spelling is أم القيوين.
Note on provenance

I am fairly sure this form is inherited from the ISO 3166-2 table rather than authored here, so this is a report that the upstream source has it wrong, not a claim that it originated in this project. I mention it because #244 says reporting data issues here is the right route for server-side updates.

I have not verified whether the other RTL-script countries have the same class of issue; I only checked that across the aggregate data the AE entries were the ones where a key and its own name differ by a combining mark.

主要语言
C++
星标
629
派生
109
30 天内没有已合并 PR

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

google/libaddressinput 的其他 Issue

查看 google/libaddressinput 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。