Page MenuHomeFreeBSD

Add Farsi/Persian locales
ClosedPublic

Authored by kfv_kfv.io on Apr 10 2020, 1:07 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Nov 2, 11:15 AM
Unknown Object (File)
Tue, Oct 29, 11:52 PM
Unknown Object (File)
Mon, Oct 21, 4:55 PM
Unknown Object (File)
Sun, Oct 20, 9:32 AM
Unknown Object (File)
Sep 25 2024, 9:36 PM
Unknown Object (File)
Sep 24 2024, 12:10 PM
Unknown Object (File)
Sep 17 2024, 9:05 PM
Unknown Object (File)
Sep 15 2024, 12:33 PM

Details

Summary

Add fa_AF.UTF-8 and fa_IR.UTF-8 locales

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Removed numericdef/fa_AF.UTF-8.src and numericdef/ar_SA.UTF-8.src since they are same with numericdef/fa_IR.UTF-8.src

This comment was removed by kfv_kfv.io.

Remove unnecessary files that were set the same as another file in Makefile

0mp edited reviewers, added: Contributor Reviews (src); removed: 0mp.

I'm sorry but I don't know how the locale generation system works + I do not have a src bit to get it committed.

lwhsu added subscribers: bapt, lwhsu.

I believe @bapt knows this. :-)

lwhsu added a subscriber: farrokhi.

@mmokhi @farrokhi : can you help verify the correctness about Farsi/Persian? Thanks!

farrokhi added inline comments.
share/numericdef/Makefile
12 ↗(On Diff #70467)

Should these be removed? Aren't you only adding fa_IR?

share/timedef/fa_IR.UTF-8.src
8

We do not have Hamza in persian alphabet. It should be written is ژانویه. The same goes for the rest of words ending with Hamza in this set.

This revision now requires changes to proceed.Jun 11 2020, 2:24 PM
share/numericdef/Makefile
12 ↗(On Diff #70467)

Yes, because of two things:

  1. They are the same, so it makes sense to have either ar_SA.UTF-8 or fa_IR.UTF-8.
  2. These are not manual changes, I've just followed /usr/src/tools/tools/locale and made the diff.

I can use the tool one more time to see if it produces anything else.

share/timedef/fa_IR.UTF-8.src
8

Completely true, but we should either add a manual change or contribute to the CLDR project on cldr.unicode.org.
Anyhow, I will do all steps one more time and will update you.

Although I think nothing's wrong with this revision since all steps are automatically done and I've made no additional change, I believe @yuripv knows much more than me about locales. So I would appreciate if he could also take a look.

share/numericdef/Makefile
12 ↗(On Diff #70467)

OK, I just double-checked and we've done nothing wrong here. It removes the ar_SA.UTF-8 from LOCALES+= and adds the fa_IR.UTF-8 instead. The rest are taken care of in SAME+= lines.

share/timedef/fa_IR.UTF-8.src
8

I redid all steps one more time and nothing's change. I will check how this could be fixed on CLDR, but I think we are fine for this revision and there is nothing to work on. But, there's something interesting that I forgot to tell you before, timedef is commented out in /usr/src/tools/tools/locale/Makefile - check line 20:

KNOWN=          monetdef numericdef msgdef colldef ctypedef # timedef

So I had to uncomment it to generate them. So maybe, it wouldn't cause any problem if we manually remove all occurrences of the trailing Hamza. Am I right? Let me know if we can do so and I will apply the change.

This revision is now accepted and ready to land.Jul 21 2020, 11:51 AM

Any blocker for this change? Just wondering.

And could anyone try to regenerate these changes by using tools/locale/locale after r364245? I updated the tools to use CLDR v35, and now it supports patches under the "patch" directory if necessary. If it works, and no one is going to work on committing them, I will volunteer to do it.

In D24359#592017, @hrs wrote:

Any blocker for this change? Just wondering.

And could anyone try to regenerate these changes by using tools/locale/locale after r364245? I updated the tools to use CLDR v35, and now it supports patches under the "patch" directory if necessary. If it works, and no one is going to work on committing them, I will volunteer to do it.

I don't think there is any serious blockers. The reason that I cannot proceed this is because I don't know how our locale system works and haven't researched it. If possible, please point me some documents or write short notes while committing this.

In D24359#592017, @hrs wrote:

Any blocker for this change? Just wondering.

And could anyone try to regenerate these changes by using tools/locale/locale after r364245? I updated the tools to use CLDR v35, and now it supports patches under the "patch" directory if necessary. If it works, and no one is going to work on committing them, I will volunteer to do it.

Sure, I'll regenerate the change within the next two days.

There is no need to regenerate as the committer should regenerate himself when commiting. Nothing is blocking it beside time from committers.

I will try to look into committing this week the MR. Thank you very much

share/numericdef/Makefile
12 ↗(On Diff #70467)

this is the generator that generates that, changes symlinks etc. So this is kind of expected

share/timedef/fa_IR.UTF-8.src
8

timedef are the only one that are maintained manually, so after I will have commit those, please submit or send me a patch with the fixed version, they will never be updated

share/timedef/fa_IR.UTF-8.src
8

Although I've come to the conclusion that the trailing Hamza we discussed with @farrokhi is not called Hamza but "یای کوتاه" which is completely fine, I will definitely do as you said and will submit a patch whenever there's something needing a change, roger that.


Reference for "یای کوتاه":

https://apll.ir/wp-content/uploads/2018/10/D-1394.pdf - pages 14, 20

Any chance we can get this in for 13.0?

This revision was automatically updated to reflect the committed changes.