Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Internationalization of the software and all content #242

Open
2 tasks
csarven opened this issue Aug 1, 2018 · 5 comments
Open
2 tasks

Internationalization of the software and all content #242

csarven opened this issue Aug 1, 2018 · 5 comments
Labels
documentation internationalization UI
Milestone
Internationalizat...

Comments

@csarven
Copy link
Member

csarven commented Aug 1, 2018

  • Software (anything in the UI)
  • Content on homepage, documentation..
@csarven
Copy link
Member Author

csarven commented Aug 1, 2018

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.

@EurekaChen
Copy link

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.

@csarven
Copy link
Member Author

csarven commented Aug 4, 2018 •
edited

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 nodeSolidServer/node-solid-server#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 #110 which covers this.

I think we should also keep the default lang in <html> regardless of which languages the content uses (in <body>).

@csarven csarven mentioned this issue Aug 4, 2018
Open
@csarven
Copy link
Member Author

csarven commented Aug 4, 2018 •
edited

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 #244 to handle this.

@EurekaChen
Copy link

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 #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
documentation internationalization UI
Projects
None yet
Milestone
Internationalization and Localization
Development

No branches or pull requests
2 participants
@csarven @EurekaChen