i18n/Add Japanese with kanji (2) #2085

Closed
hakabahitoyo wants to merge 2 commits from gitlab-mr-iid-816 into develop
Member

Resolves #522.

Update version of #2079.

image

Resolves #522. Update version of #2079. ![image](/attachments/6be46dc2-a552-4113-86a1-1f4757e96a03)
2.4 MiB
Owner

no need for this.

The core idea is: ja.json has everything, ja_pedantic.json only has things that should be changed. For example both files have "title": "チャット" so it could be deleted from ja_pedantic.json, same goes for everything that's identical for both files. This would remove the need to update both files every time something is changed or added, less chance that someone forgets to update the other file, and also it would save space.

What this line does - it takes ja_pedantic.json and overrides things from it with everything in ja.json which is pointless.

I hope my explanation was easy to understand.

no need for this. The core idea is: `ja.json` has everything, `ja_pedantic.json` only has things that should be changed. For example both files have `"title": "チャット"` so it could be deleted from `ja_pedantic.json`, same goes for everything that's identical for both files. This would remove the need to update both files every time something is changed or added, less chance that someone forgets to update the other file, and also it would save space. What this line does - it takes `ja_pedantic.json` and overrides things from it with everything in `ja.json` which is pointless. I hope my explanation was easy to understand.
Author
Member

There are some concerns about that:

  1. The /src/i18n/compare tool does not suit for the partial (removing duplicates) resource.
  2. Duplicates between ja.json and js_pedantic.json are not so much. チッャト or all-katakana messages are less than 25 % of all.
  3. Fallbacking ja.json and ja_pedantic.json each other may better than fallbacking into English.
There are some concerns about that: 1. The `/src/i18n/compare` tool does not suit for the partial (removing duplicates) resource. 1. Duplicates between `ja.json` and `js_pedantic.json` are not so much. `チッャト` or all-katakana messages are less than 25 % of all. 1. Fallbacking `ja.json` and `ja_pedantic.json` each other may better than fallbacking into English.
Owner
  1. compare tool will be updated later to handle this case.
  2. still worth de-duplicating it imo
  3. it will fall back to english anyway if string is missing from both.

keeping strings duplicated it would lead to a messy state imo

1. compare tool will be updated later to handle this case. 2. still worth de-duplicating it imo 3. it will fall back to english anyway if string is missing from both. keeping strings duplicated it would lead to a messy state imo
Owner

And ja.json and ja_pedantic.json must be maintained separately. Removing duplicates forces extra work of us. Further I have no assumption about which of ja.json and ja_pedantic.json is mainline and is optional for future developers, symmetric fallbacking may be a good compromise.

dunno where gitlab shoved your comment but i got the email at least

>And ja.json and ja_pedantic.json must be maintained separately. Removing duplicates forces extra work of us. Further I have no assumption about which of ja.json and ja_pedantic.json is mainline and is optional for future developers, symmetric fallbacking may be a good compromise. dunno where gitlab shoved your comment but i got the email at least
Owner

ja.json is the "main" one because it will be used by default if user hasn't selected locale and his system locale is japanese.

ja.json is the "main" one because it will be used by default if user hasn't selected locale and his system locale is japanese.
Owner

if you want, i can remove duplicates for you after the merge if it's that hard. however falling back this way is still pointless imo - either there are duplicates and no fallback or no duplicates and one-way fallback

if you want, i can remove duplicates for you after the merge if it's that hard. however falling back this way is still pointless imo - either there are duplicates and no fallback or no duplicates and one-way fallback
Author
Member

Now I prefer there are duplicates and no fallback.

Now I prefer _there are duplicates and no fallback_.

Pull request closed

Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma-fe!2085
No description provided.