dokieli
dokieli copied to clipboard
linkeddata
Internationalization of the software and all content
Software should be able to adjust in a number of different ways. For language, if the signed in user's profile indicates their "preferredLanguage", dokieli can use that automatically. That can be in addition to having the UI offer a language options for the whole interface, as well as assigning a language for annotations and the language of a piece of (selected) content.
For the translation of dokeili documents, I have created an example here: Display Chinese and English bilingual: https://dac.xyz/dokieli/docs.html, We can show only English with: https://dac.xyz/dokieli/docs.html?lang=en Or show only Chinese here: https://dac.xyz/dokieli/docs.html?lang=zh You can also switch languages by using two simple buttons on the page.
In translation, I simply added the tag in the html markup, and used the language atrribute lang= "en" and lang= "zh" (so, we can using any languge code), which you can see HTML source code in detail. Then switch language through very simple JavaScript. Therefore, the whole article retains all the original English text without information loss, while adding Chinese content. Other language translations can also be added in a similar way. Do you think this method can be used in other aspects of dokieli internationalization?
In addition, the content of the article was translated by me manually, but some hasty. Because I'm familiar with the terminology of Linked Data, so I hope this translation will be helpful. I have now pushed the document to GitHub: Https://github.com/EurekaChen/dokieli/blob/master/docs.html I can pull request the document if necessary.
That's a major step, thank you! Let's see how we can integrate this in..
Some initial feedback:
My feeling is to keep each language in different files because compressing all languages into a single may not be ideal for long term - scale issue. Also an update to a single language would require all other languages to be updated in the same file. Separate files per language on the other would keep them self-contained. On the other hand, separate files requires some server logic to return the correct file on disk.
I've created https://github.com/solid/node-solid-server/issues/735 to keep this in parallel so that we can see options on how to align behaviour.
The UI (buttons to switch languages) should be part of dokieli.js - a separate 1) issue 2) PR would be great. I'm not sure what would be the best UI for this at the moment, but my initial thought - and keeping existing markup patterns in dokieli - is that each language should be listed as a hyperlink as base eg:
<dl id="document-languages">
<dt>Languages</dt>
<dd><a href="foo.en" lang="en" xml:lang="en">English</a></dd>
<dd><a href="foo.zh" lang="zh" xml:lang="zh">中文</a></dd>
</dl>
foo could also serve as the initial language.
If JavaScript needs to be used, it should only be as an enhancement - but right now I don't see a requirement for it. This can be explored in its own issue.
I think what we need is an UI to create that document-languages block, and assign URLs. See also https://github.com/linkeddata/dokieli/issues/110 which covers this.
I think we should also keep the default lang in <html> regardless of which languages the content uses (in <body>).
As for the multilingual support of the application itself, I think we would move all human-readable content into DO.C.Text and use something like DO.C.Lang (it is there but unused) to output the desired language. Created https://github.com/linkeddata/dokieli/issues/244 to handle this.
Thank you for your reply! First of all, you did consider a lot, in all aspects of the more comprehensive consideration. But I have the following immature ideas:
For Software (UI)： We need use separate files to indicate which lang can be. Like some PHP framework(Wordpress,drupal) and Python framework (Django) are using Potable Object files(.po) for internationalize, and Windows Store App , such as my multi-language App Eureka Clock is the use of resource files to express various languages. Therefore, in a variety of platforms, software UI, it is certainly more appropriate to use multiple file representations. So I do not suggest a multiple language representation in one Config file, as https://github.com/linkeddata/dokieli/issues/244 shows. I suggest that we can separate them to different files, like .po files in other framework.
For web page(Documents): You are right, it is not good to put all the multi-language translations in one file, It can not scale. But we translate a documents only need two languages, one is the source language and the other is the target language. A translation document is generally only available in two languages. The purpose of putting it in the same document is to make it easier for the reader to control it, because the translation may be distorted or even get original author's intent wrong. So the purpose of putting the original text in the same document is that the source text (intent of the original author) is not distorted, and allows the reader to judge some of the distorted statements themselves.
The purpose of my translation of the dokieli doc into Chinese was just for the Chinese community to understand dokieli. And it's the most convenient way by adding Chinese into the original file, do not need server support, and do not need negotiation. I think keep the original lang in regardless of which languages the content uses is no problem. English is the most widely used, and Chinese is the most people used, Hope a good solution soon.