cnrv/home

Proposal: Adding Traditional Chinese Translation

Closed this issue · 15 comments

NonerKao commented

Hi all,

I am a friend of 黃柏瑋's.
We think that providing a traditional Chinese version of this awesome biweekly might help raise the attention of RISC-V technology to TC community. We have found an automatic way to do the translation, and I will be responsible for the process.

I would like to send PRs containing the following changes to this repository:

  • rename the bi-week-rpts directory into bi-week-rpts-sc
  • create a new directory named bi-week-rpts-tc
  • translate the past issues and put them in bi-week-rpts-tc

Once the process is stable, we can synchronously proceed the translation as the current issue is editted.

How would you like this idea?

wsong83 commented

What about a Makefile that can automatically generate traditional md from the simplified ones?
In that way, we just need to run a make every time there is a new newsletter.
There is even a possibility to deploy the make process in ci-travis, which then directly publishes it online without actually committing the traditional ones in GitHub.

  • 👍1
poweihuang17 commented

Thanks Kao. wei, we got your point, and we concluded that we could start from automatically translate the "字體" and leave "術語" as a future work. Thank for your comment, wei.

  • 👍1
NonerKao commented

@wsong83
Good idea!
I will do some survey and then make a PR containing a workable makefile.

wsong83 commented

@poweihuang17
Ah, I see. Simplified to traditional is not just character mapping. Sorry for my being naive here. :-)

wsong83 commented

I just wonder, Wikipedia seems to have a very good simplified/traditional conversion. Is that a manual work?

poweihuang17 commented

Not sure. Let me check that with Kao.

NonerKao commented

@wsong83 Not big deal. Take it easy!
For this biweekly, we may first do this step by step.

Actually, considering the context, the auto-conversion of Wikipedia is not acceptable in many cases.
You may found some article in SC but reading weird, because the original content is written by some TC users, and vice versa.
That's the classical example of pure character mapping.

NonerKao commented

Sorry for the delay.
I have been trying to figure out how this, the SC-TC translation, should work.

In previous discussions we came up with the idea of using Makefile. However, using such a automation tool would turn the readers of this bi-weekly, a technical journal, into users of this archive, a software repository. The two offer tremendously different user experiences.

The best way I can think of is that, by providing some 簡繁轉換 button on top of the index page, readers can easily choose their preference language to read. There are at least two implementation choices:

  • Static content: We provide a patch with a Makefile, and before deployment, the website maintainers run the make command to generate the TC content.
    Pros: no structural change;
    Cons: more work on the maintainer side.
  • Dynamic translation: We provide a patch to the web sources, which embed some javascript codes that can dynamically translate the SC into TC.
    Pros: no extra storage. no more maintainer work.
    Cons: add new dependency to node.js.

Which do you prefer, or any other ideas?

Sorry for being annoying on tedious things. But I think such discussions would benefit all cross-straight RISC-V enthusiasts.

poweihuang17 commented

@NonerKao Thanks for your work. For the work of static content, if you could provide an easy readme or instruction list to tell us how to use it, I guess it's no big deal. For dynamic part, it all depends on whether you could afford that.

wsong83 commented

I think I do like the dynamic idea. Sorry I am not very familiar with website designs. Would this javascript and Node.js cause any inconvenience on user experience? For example, does the browser's default setting allow the using of Node.js? It would be considered as a security warning?
@xfguo Is it possible to deploy Node.js script in our website? Is this allowed by the server?

Another concern is, the dynamic method relies on a perfect (or production ready) run-time translation script. I believe can be tricky? The static method can tolerate some imperfection. We can run Makefile manually at first, fixing the imperfect translation by hands. Then deploy it automatically when it is ready.

I think may be the other argument makes sense. Once we get a static method working, it is not far away from the dynamic method. Would implementing the static one first help with the dynamic method? Would it be useful if we can implement it gradually?

NonerKao commented

@wsong83
To be honest, I am not familiar with web design either. I have consulted some experienced guys, they don't recommend the dynamic way, since node.js libraries is not for front-end, and we will need many workaround to just make it work.

So, I think it is clear now that we may just do the static one, and wait and see if there are any front-end technology that is suitable for our future needs.

Thanks for all the attention and discussion. I'll make the patch recently, which should contain some minor addition to web site part and mostly the Makefile.

poweihuang17 commented

@NonerKao Thank you!

  • 🎉1
poweihuang17 commented

@wsong83 Thanks for your attention and feedback.

  • 🎉1
poweihuang17 commented

我先把這個關了，除非有天有需要或又有心力做自動繁體轉換。