Coordinating zh_TW (Taiwanese Mandarin) Translations
Hi all, This is Adrian from Taiwan, I'm currently a core organising staff at PyCon TW, and I would like to volunteer as the coordinator of zh_TW (Taiwanese Mandarin) translations! The current translations (although it's not complete enough to add it to the language switcher) are hosted on our own GitHub repository ( https://github.com/python-doc-tw/cpython-tw/tree/tw-3.6/Doc/locale/zh_TW/LC_...) and on our own Transifex project ( https://www.transifex.com/python-tw-doc/python-36-tw), and I would like to migrate them into the PEP 545 workflow. However, I have a concern here, if I migrate the translations to the official Transifex project for Python documentation translations, that way it may completely lost the metadata of each string including history and translator, which I think is probably a bad thing to happen. I'm wondering if anyone knows whether there's some way to solve this problem or it's currently an unsupported feature (migrating translation metadata along with the translations) on Transifex? Thank you for taking time reading this, thank you for your contributions, and I'm super excited about making more contributions to the Python community! Best Regards, Wey-Han "Adrian" Liaw -- Wey-Han "Adrian" Liaw (@adrianliaw) http://linkedin.com/in/adrianliaw
Hi Adrian, It's nice to get news from zh_TW!
This is Adrian from Taiwan, I'm currently a core organising staff at PyCon TW, and I would like to volunteer as the coordinator of zh_TW (Taiwanese Mandarin) translations!
Having a coordinator for zh_TW would be great, and we do not have one... so welcome abord!
However, I have a concern here, if I migrate the translations to the official Transifex project for Python documentation translations
The transifex project is not official, it may looks like official because almost everyone is using it, but it's not mandatory to use it. Every country is free to use their own tool to coordinate their translation, we do not make Transifex mandatory.
that way it may completely lost the metadata of each string including history and translator, which I think is probably a bad thing to happen. I'm wondering if anyone knows whether there's some way to solve this problem or it's currently an unsupported feature (migrating translation metadata along with the translations) on Transifex?
I don't really know Transifex, but feel free to either ask them directy and/or stay in your own transifex organisation.
Thank you for taking time reading this, thank you for your contributions, and I'm super excited about making more contributions to the Python community!
Thank you for contributing! Feel free to ask a repository on the cpython organization when you feel ready to migrate there. You'll have to use the same file hierarchy as other repos in order to have the docsbuild-scripts working with them, like : https://github.com/python/python-docs-fr or https://github.com/python/python-docs-ja. It means to have a branch per version you translate, you're free to maintain the versions you like, a single one is OK, the branch name have to be the version (like "3.6"), and .po" files in the root of the repository, with "gettext_compact=0". Feel free to copy or simply get inspiration from https://github.com/python/python-docs-fr/tree/3.6/Makefile to create the hierarchy / merge from upstream, sync with transifex (I use a local "transifex" branch to tx pull and tx push, the git to merge to/from the transifex branch). Bests, -- Julien Palard https://mdk.fr
Migrating Transifex project is not mandatory. If you don't have any problem about current project, I recommend you to keep your project. On the other hand, you need to migrate Github repository. I don't know that "tw" is valid IETF language tag or not. If so, the repository name will be github.com/python/python-docs-tw Regards, On Sat, May 26, 2018 at 10:10 PM Adrian Liaw <adrianliaw2000@gmail.com> wrote:
Hi all,
This is Adrian from Taiwan, I'm currently a core organising staff at PyCon TW, and I would like to volunteer as the coordinator of zh_TW (Taiwanese Mandarin) translations!
The current translations (although it's not complete enough to add it to the language switcher) are hosted on our own GitHub repository ( https://github.com/python-doc-tw/cpython-tw/tree/tw-3.6/Doc/locale/zh_TW/LC_...) and on our own Transifex project ( https://www.transifex.com/python-tw-doc/python-36-tw), and I would like to migrate them into the PEP 545 workflow.
However, I have a concern here, if I migrate the translations to the official Transifex project for Python documentation translations, that way it may completely lost the metadata of each string including history and translator, which I think is probably a bad thing to happen. I'm wondering if anyone knows whether there's some way to solve this problem or it's currently an unsupported feature (migrating translation metadata along with the translations) on Transifex?
Thank you for taking time reading this, thank you for your contributions, and I'm super excited about making more contributions to the Python community!
Best Regards, Wey-Han "Adrian" Liaw -- Wey-Han "Adrian" Liaw (@adrianliaw) http://linkedin.com/in/adrianliaw _______________________________________________ Doc-SIG maillist - Doc-SIG@python.org https://mail.python.org/mailman/listinfo/doc-sig
-- INADA Naoki <songofacandy@gmail.com>
I don't know that "tw" is valid IETF language tag or not. If so, the repository name will be github.com/python/python-docs-tw
"tw" is the language tag for Twi (https://en.wikipedia.org/wiki/Twi), we can't use it for this translation. "zh" is the language tag for Chinese, it can be followed by subtags. "TW" is the region subtag for Taiwan. So if "Chinese as spoken in Taiwan" is the language Adrian is translating, the repository will be named "python-docs-zh-tw". According to PEP 545 (and BCP-47) we should *not* use subtags if it does not add usefull information. Typically "fr-FR" "French as spoken in France" is kind of redundent and should be simplified "fr". So can we simplify "zh-tw" to "zh"? I don't think so, as there is another project, "zh-cn" (https://zhsj.github.io/python-docs-zh-cn/), but as I don't speak chinese, I think Adrian also have its word on it. -- Julien Palard https://mdk.fr
So can we simplify "zh-tw" to "zh"? I don't think so, as there is another
On Sat, May 26, 2018 at 10:14 PM Julien Palard via Doc-SIG < doc-sig@python.org> wrote: project, "zh-cn" (https://zhsj.github.io/python-docs-zh-cn/), but as I don't speak chinese, I think Adrian also have its word on it. Thanks for mentioning my repo. It's used for previewing the Chinese(China) translation on transifex[1]. There are Simplified Chinese and Traditional Chinese, the former is mostly used in China mainland and latter in Taiwan. It's complicated to indicate these two languages in RFC 5646. The formal should be zh-Hans-CN, and zh-Hant-TW. Because there's also zh-Hans-SG(Simplified Chinese used in Singapore)/zh-Hant-HK(Traditional Chinese used in Hongkong)/etc... You can see all the language tags beginning with zh- prefix in iana[2] However it's common to see zh-cn/zh-tw in various open source projects, especially in sphinx[3]. So I'd like to keep using zh-cn and zh-tw as I didn't see there's much translation effort in other varieties. BTW, for zh_CN translations, we are slow at reaching the coverage. However I've contacted Xiang Zhang(The only person I known using Chinese and also a core developer) to get the work organized. [1] https://www.transifex.com/python-doc/dashboard/all_projects/zh_CN/ [2] https://www.iana.org/assignments/language-subtag-registry/language-subtag-re... [3] https://github.com/sphinx-doc/sphinx/tree/master/sphinx/locale -- Regards, Shengjing Zhu
So I'd like to keep using zh-cn and zh-tw as I didn't see there's much translation effort in other varieties.
OK, works for me. And if in the future they start translating we'll still be able to affect them specific tags as needed, like zh-Hant-HK, we're not locking them out by choosing zh-cn and zh-tw.
BTW, for zh_CN translations, we are slow at reaching the coverage. However I've contacted Xiang Zhang(The only person I known using Chinese and also a core developer) to get the work organized.
Xiang Zhang told in january 2018 he won't be "as free as before" [1], already in a discussion about chinese translations : https://mail.python.org/pipermail/doc-sig/2018-January/003991.html. [1]: https://mail.python.org/pipermail/doc-sig/2018-January/003994.html -- Julien Palard https://mdk.fr
Thanks everyone for your great comments and all the useful informations. I'd say I'm agreeing with using zh-tw language tag. And I personally believe adding "Hant" or "Hans" tag is somehow redundant, the reason is that you can usually assume its writing system by region. e.g. you can assume zh-cn to be written in Simplified Chinese, zh-tw to be in Traditional Chinese, zh-hk (Hong Kong Cantonese) to be in Traditional Chinese, zh-sg (Singaporean Mandarin) to be in Simplified Chinese, etc. Regarding the repository setup that Julien mentioned earlier, big thanks to Julien for providing lots of inspirations, I'll stay with our own Transifex project, and I'll setup the project and a proper contribution workflow, I'll get back to you as soon as I done it! Best Regards, Adrian On Sun, 27 May 2018 at 02:08 Julien Palard via Doc-SIG <doc-sig@python.org> wrote:
So I'd like to keep using zh-cn and zh-tw as I didn't see there's much translation effort in other varieties.
OK, works for me. And if in the future they start translating we'll still be able to affect them specific tags as needed, like zh-Hant-HK, we're not locking them out by choosing zh-cn and zh-tw.
BTW, for zh_CN translations, we are slow at reaching the coverage. However I've contacted Xiang Zhang(The only person I known using Chinese and also a core developer) to get the work organized.
Xiang Zhang told in january 2018 he won't be "as free as before" [1], already in a discussion about chinese translations : https://mail.python.org/pipermail/doc-sig/2018-January/003991.html.
[1]: https://mail.python.org/pipermail/doc-sig/2018-January/003994.html
-- Julien Palard https://mdk.fr
_______________________________________________ Doc-SIG maillist - Doc-SIG@python.org https://mail.python.org/mailman/listinfo/doc-sig
-- Wey-Han "Adrian" Liaw (@adrianliaw) http://linkedin.com/in/adrianliaw
Hi all, I think we're ready to migrate our repository as we've set up all the requirements for docsbuild-scripts to work, it has currently only 3.6 branch which has the same hierarchy as other translation repos, and master branch for informations for translators. The current repo is at https://github.com/python-doc-tw/python-docs-zh-tw, I've requested a repository transfer to Python's GitHub organisation, please approve if it's appropriate. Thank you! Best Regards, Adrian On Sun, 27 May 2018 at 20:38 Adrian Liaw <adrianliaw2000@gmail.com> wrote:
Thanks everyone for your great comments and all the useful informations.
I'd say I'm agreeing with using zh-tw language tag. And I personally believe adding "Hant" or "Hans" tag is somehow redundant, the reason is that you can usually assume its writing system by region. e.g. you can assume zh-cn to be written in Simplified Chinese, zh-tw to be in Traditional Chinese, zh-hk (Hong Kong Cantonese) to be in Traditional Chinese, zh-sg (Singaporean Mandarin) to be in Simplified Chinese, etc.
Regarding the repository setup that Julien mentioned earlier, big thanks to Julien for providing lots of inspirations, I'll stay with our own Transifex project, and I'll setup the project and a proper contribution workflow, I'll get back to you as soon as I done it!
Best Regards, Adrian
On Sun, 27 May 2018 at 02:08 Julien Palard via Doc-SIG <doc-sig@python.org> wrote:
So I'd like to keep using zh-cn and zh-tw as I didn't see there's much translation effort in other varieties.
OK, works for me. And if in the future they start translating we'll still be able to affect them specific tags as needed, like zh-Hant-HK, we're not locking them out by choosing zh-cn and zh-tw.
BTW, for zh_CN translations, we are slow at reaching the coverage. However I've contacted Xiang Zhang(The only person I known using Chinese and also a core developer) to get the work organized.
Xiang Zhang told in january 2018 he won't be "as free as before" [1], already in a discussion about chinese translations : https://mail.python.org/pipermail/doc-sig/2018-January/003991.html.
[1]: https://mail.python.org/pipermail/doc-sig/2018-January/003994.html
-- Julien Palard https://mdk.fr
_______________________________________________ Doc-SIG maillist - Doc-SIG@python.org https://mail.python.org/mailman/listinfo/doc-sig
-- Wey-Han "Adrian" Liaw (@adrianliaw) http://linkedin.com/in/adrianliaw
-- Wey-Han "Adrian" Liaw (@adrianliaw) http://linkedin.com/in/adrianliaw
Sorry, let me correct my previous message, I failed to request a transfer, seems like we'll need a repository in Python's GitHub organisation. Thanks! Best Regards, Adrian On Sat, 23 Jun 2018 at 03:18 Adrian Liaw <adrianliaw2000@gmail.com> wrote:
Hi all,
I think we're ready to migrate our repository as we've set up all the requirements for docsbuild-scripts to work, it has currently only 3.6 branch which has the same hierarchy as other translation repos, and master branch for informations for translators. The current repo is at https://github.com/python-doc-tw/python-docs-zh-tw, I've requested a repository transfer to Python's GitHub organisation, please approve if it's appropriate. Thank you!
Best Regards, Adrian
On Sun, 27 May 2018 at 20:38 Adrian Liaw <adrianliaw2000@gmail.com> wrote:
Thanks everyone for your great comments and all the useful informations.
I'd say I'm agreeing with using zh-tw language tag. And I personally believe adding "Hant" or "Hans" tag is somehow redundant, the reason is that you can usually assume its writing system by region. e.g. you can assume zh-cn to be written in Simplified Chinese, zh-tw to be in Traditional Chinese, zh-hk (Hong Kong Cantonese) to be in Traditional Chinese, zh-sg (Singaporean Mandarin) to be in Simplified Chinese, etc.
Regarding the repository setup that Julien mentioned earlier, big thanks to Julien for providing lots of inspirations, I'll stay with our own Transifex project, and I'll setup the project and a proper contribution workflow, I'll get back to you as soon as I done it!
Best Regards, Adrian
On Sun, 27 May 2018 at 02:08 Julien Palard via Doc-SIG < doc-sig@python.org> wrote:
So I'd like to keep using zh-cn and zh-tw as I didn't see there's much translation effort in other varieties.
OK, works for me. And if in the future they start translating we'll still be able to affect them specific tags as needed, like zh-Hant-HK, we're not locking them out by choosing zh-cn and zh-tw.
BTW, for zh_CN translations, we are slow at reaching the coverage. However I've contacted Xiang Zhang(The only person I known using Chinese and also a core developer) to get the work organized.
Xiang Zhang told in january 2018 he won't be "as free as before" [1], already in a discussion about chinese translations : https://mail.python.org/pipermail/doc-sig/2018-January/003991.html.
[1]: https://mail.python.org/pipermail/doc-sig/2018-January/003994.html
-- Julien Palard https://mdk.fr
_______________________________________________ Doc-SIG maillist - Doc-SIG@python.org https://mail.python.org/mailman/listinfo/doc-sig
-- Wey-Han "Adrian" Liaw (@adrianliaw) http://linkedin.com/in/adrianliaw
-- Wey-Han "Adrian" Liaw (@adrianliaw) http://linkedin.com/in/adrianliaw
-- Wey-Han "Adrian" Liaw (@adrianliaw) http://linkedin.com/in/adrianliaw
Hi Adrian, I created the repository https://github.com/python/python-docs-zh-tw and invited you with commit rights on it. -- Julien Palard https://mdk.fr
Hi Julien, Thanks a lot! I've moved our repository there. Cheers! On Sun, 24 Jun 2018 at 14:22 Julien Palard <julien@palard.fr> wrote:
Hi Adrian,
I created the repository https://github.com/python/python-docs-zh-tw and invited you with commit rights on it.
-- Julien Palard https://mdk.fr
-- Wey-Han "Adrian" Liaw (@adrianliaw) http://linkedin.com/in/adrianliaw
participants (4)
-
Adrian Liaw -
INADA Naoki -
Julien Palard -
Shengjing Zhu