Using the Arabic Names for edition `name` field

[vipafattal]

Since there is an englishName field in editions which its value obviously is in English, so as far as I think, it makes sense that name value to be in Arabic or at least the ar editions.

So for example, if I may suggest that the name field would be:

Quran simple (ar.quran-simple-clean) => rename: Simple Clean to القرآن الكريم البسيط (بدون تشكيل) Quran Uthmani (ar.quran-uthmani-quran-academy) => rename: Quran Uthmani by Quran Academy to القرآن الكريم برسم العثماني Quran Mujawad (ar.quran-uthmani-quran-academy) => rename: Tajweed to قرآن مجود (ملون)

[meezaan]

Makes sense to me. Would you kind enough to provide the names?

Arabic editions are: http://api.alquran.cloud/v1/edition/language/ar and many of the ones that aren't the actual text already have Arabic names.

[vipafattal]

Alright then, I'd be more than happy to help!

For easiness, I will create a google sheet list of all the Arabic name suggestions that I could make.

[vipafattal]

You can see the list of the suggested Arabic name at: https://docs.google.com/spreadsheets/d/1WU3bKsAoksgW0OcwnXW71kYyeNW03nVXLimS0CHRDNI/edit?usp=sharing

[meezaan]

JazakAllah! I will have a look.

[vipafattal]

I proposed in the spreadsheet that we move quran-wordbyword-2 & quran-wordbyword to English editions instead of Arabic since they are not related directly to Arabic users but users that are coming from English, but didn't have any word from you @meezaan.

[meezaan]

@vipafattal Sorry I have not actually got to this issue yet.

But the word-by-word editions are not listed with an ar. They are with the quran- prefix because they also contain the Arabic text.

[meezaan]

JazakAllah for adding the Arabic names. Insha'Allah I will try to add them to the API over the next few days.

[vipafattal]

@vipafattal Sorry I have not actually got to this issue yet.

But the word-by-word editions are not listed with an ar. They are with the quran- prefix because they also contain the Arabic text.

Never mind taking your time,

I understand that Quran, but let's say that this endpoint http://api.alquran.cloud/v1/edition/language/ar will be used to show Arabic users what books the API has, however, the response will be containing some editions (such as word by word, quran-buck) that will never be used by Arabic user's though it contains Arabic text.

I think the end-user of the API will be confused, not to mention that categorized editions by language using the endpoint of [http://api.alquran.cloud/v1/edition], that would be a serious issue for multilanguage users, since everyone will go his category (please take a look at images below).

I hope that I was able to explain my point.

[meezaan]

I completely understand the point, but in actual microservices architecture this would be dealt with by the service or viewModel that deals with data specifically for the view, not in the microservice dealing with languages of the editions. Making core data APIs applicable to specific UIs is problematic (because everyone will have a different requirement), because, for instance, the indicator can mean these results contain Arabic as opposed to these results are only Arabic.

However, this may be something we can deal with using a query parameter. So you might pass something like multiLingual=false and that only brings back Arabic text.

In principle, I disagree with this approach, but I'm not particularly hung up on it.

If you'd still like to do it, it's best to create a separate issue.

[meezaan]

@vipafattal FYI the names have now been updated.

[vipafattal]

Wow amazing JazakAllah!

I noticed there is a small typo, you are dropping ALEF in: "name": "لقرآن الكريم المبسط (تشكيل بسيط)", quran-simple "name": "لقرآن الكريم المبسط (بدون تشكيل)", quran-simple-clean "name": "لقرآن الكريم المبسط (بدون تشكيل)", quran-simple-enhanced "name": "لقرآن الكريم المبسط (بدون تشكيل)", quran-simple-min

[vipafattal]

I completely understand the point, but in actual microservices architecture this would be dealt with by the service or viewModel that deals with data specifically for the view, not in the microservice dealing with languages of the editions. Making core data APIs applicable to specific UIs is problematic (because everyone will have a different requirement), because, for instance, the indicator can mean these results contain Arabic as opposed to these results are only Arabic.

However, this may be something we can deal with using a query parameter. So you might pass something like multiLingual=false and that only brings back Arabic text.

In principle, I disagree with this approach, but I'm not particularly hung up on it.

If you'd still like to do it, it's best to create a separate issue.

Exactly it would mostly fit into the ViewModel, it turns out I was generalizing my own requirements. sorry for that.

[vipafattal]

Wow amazing JazakAllah!

I noticed there is a small typo, you are dropping ALEF in: "name": "لقرآن الكريم المبسط (تشكيل بسيط)", quran-simple "name": "لقرآن الكريم المبسط (بدون تشكيل)", quran-simple-clean "name": "لقرآن الكريم المبسط (بدون تشكيل)", quran-simple-enhanced "name": "لقرآن الكريم المبسط (بدون تشكيل)", quran-simple-min

Salam Meezaan, Just want to inform you that there is mistake in the Arabic names, you have dropped the first letter "ا" (Alef) in some editions.

[meezaan]

Will have a look and fix ASAP. Thanks

[meezaan]

Updated @vipafattal.