AE: Sharjah sub-key has a shadda on the teh marbuta (إمارة الشارقةّ)
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 64/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- cpp
- Lĩnh vực
- localization
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- 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. ام القيوين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.
- Ngôn ngữ chính
- C++
- Star
- 629
- Fork
- 109
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của google/libaddressinput
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
google/libaddressinput#255 ·
-
Improve Spain postcode regexĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
google/libaddressinput#245 · 1 bình luận ·
-
Error in Spain sub_zip listĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 52/100
google/libaddressinput#250 · 2 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 58/100
google/libaddressinput#249 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 45/100
google/libaddressinput#244 · 2 bình luận ·
Tất cả issue của google/libaddressinput
Issue tương tự
-
needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
flashinfer-ai/flashinfer#6212 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug graphics
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
FlaxEngine/FlaxEngine#4295 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Algorithmiq/monoprop#390 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
docs
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
leethomason/tinyxml2#1097 ·