Add zh-Hant translation #107

Merged
kisaragi-hiu merged 2 commits from zh-hant into main 2025-05-12 12:21:44 +03:00
kisaragi-hiu commented 2025-05-12 05:08:06 +03:00 (Migrated from github.com)

This was translated independently from zh-Hans, with the exception that after translating a few strings I had looked at the zh-Hans translation for context, such as translating Audio Offloading as Audio Hardware Acceleration, as well as looking at how plural works.

I took the XML file, used android2po from Translate Toolkit to convert it into Gettext PO so I can translate it locally with Lokalize, then "converted" it back by making a copy of the English XML and manually (with help of Emacs macros) copying strings back, carefully converting the msgstr syntax to the XML.

This was translated independently from zh-Hans, with the exception that after translating a few strings I had looked at the zh-Hans translation for context, such as translating Audio Offloading as Audio Hardware Acceleration, as well as looking at how plural works. I took the XML file, used `android2po` from Translate Toolkit to convert it into Gettext PO so I can translate it locally with Lokalize, then "converted" it back by making a copy of the English XML and manually (with help of Emacs macros) copying strings back, carefully converting the msgstr syntax to the XML.
TJYSunset commented 2025-05-12 12:41:57 +03:00 (Migrated from github.com)

Thank you for your contribution!

A question: since I also author the zh-Hans strings but unfortunately can't write zh-Hant - what's the best approach for prefilling future strings in your opinion?

  • Do nothing; strings would be displayed as en
  • Copy from zh-Hans verbatim
  • Convert from zh-Hans
    Example result by OpenCC: 本應用需要“讀取音頻文件”權限才能正常工作。請授予以繼續。
  • Machine translate from en
    Example result by Google Translate: 基本功能需要讀取您的音訊檔案的權限。請允許繼續。
  • Machine translate from zh-Hans
    Example result by Google Translate: 本應用程式需要「讀取音訊檔案」權限才能正常運作。請授予以繼續。
Thank you for your contribution! A question: since I also author the zh-Hans strings but unfortunately can't write zh-Hant - what's the best approach for prefilling future strings in your opinion? - Do nothing; strings would be displayed as en - Copy from zh-Hans verbatim - Convert from zh-Hans Example result by [OpenCC](https://github.com/BYVoid/OpenCC): `本應用需要“讀取音頻文件”權限才能正常工作。請授予以繼續。` - Machine translate from en Example result by Google Translate: `基本功能需要讀取您的音訊檔案的權限。請允許繼續。` - Machine translate from zh-Hans Example result by Google Translate: `本應用程式需要「讀取音訊檔案」權限才能正常運作。請授予以繼續。`
kisaragi-hiu commented 2025-05-12 14:16:59 +03:00 (Migrated from github.com)

Thanks for caring about zh-Hans and zh-Hant differences...!

My opinion is that OpenCC from zh-Hans is best in this case, followed by leaving blank. Even though that will leave some unidiomatic zh-Hant in the new text, it's still better for the user that way as it's very unlikely to be inaccurate in this case. Converting with 繁化姬 is also an option, as it gives more idiomatic zh-Hant.

Other options all have major problems, which I'll go through first:

  • Copying from zh-Hans is strictly worse than leaving blank, as users who want fallback to zh-Hans can already set so in system settings.
  • MTL from either zh-Hans or English both are far more likely to be inaccurate, whereas conversion at worse is just inconsistent.

Comparing conversion and leaving blank (letting Android handle fallback):

  • for very complicated apps like an entire desktop environment or something like Blender (10000s of strings), there are enough differing word choices such that a mix of idiomatic zh-Hant and converted zh-Hans would introduce more than unidiomatic usages and spill into ambiguities. In that case leaving blank for fallback is better.
  • But for a music player, I think it's fine if new strings are converted. Unidiomatic zh-Hant 文件 for File, for instance, doesn't lead to misunderstandings here because this app is unlikely to distinguish between Documents and Files.
Thanks for caring about zh-Hans and zh-Hant differences...! My opinion is that OpenCC from zh-Hans is best in this case, followed by leaving blank. Even though that will leave some unidiomatic zh-Hant in the new text, it's still better for the user that way as it's very unlikely to be inaccurate in this case. Converting with [繁化姬](https://zhconvert.org/) is also an option, as it gives more idiomatic zh-Hant. Other options all have major problems, which I'll go through first: - Copying from zh-Hans is strictly worse than leaving blank, as users who want fallback to zh-Hans can already set so in system settings. - MTL from either zh-Hans or English both are far more likely to be inaccurate, whereas conversion at worse is just inconsistent. Comparing conversion and leaving blank (letting Android handle fallback): - for very complicated apps like an entire desktop environment or something like Blender (10000s of strings), there are enough differing word choices such that a mix of idiomatic zh-Hant and converted zh-Hans would introduce more than unidiomatic usages and spill into ambiguities. In that case leaving blank for fallback is better. - But for a music player, I think it's fine if new strings are converted. Unidiomatic zh-Hant 文件 for File, for instance, doesn't lead to misunderstandings here because this app is unlikely to distinguish between Documents and Files.
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
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
novvux/Blissid!107
No description provided.