-
-
Notifications
You must be signed in to change notification settings - Fork 48
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
Implement website language switching mechanism #2930
Comments
See @tokideveloper's comment: #2652 (comment). |
My proposed poor man solution (#2652 (comment)) has some advantages and disadvantages and there are many ways how to implement it. Here my thoughts (no indentation means new thought; indentation means related thought; bold means solution):
Feel free to discuss this or propose another suggestion. |
Currently, I dive into the Liquid template engine. Hopefully, I'll find smart way to create language switches with it. |
@andrewdavidwong: Please note, since I can't read Portuguese, I left some phrases in English. As you might see, it works for both relative and absolute links. Using relative links, there is no need to adapt links within the documentation. As you might see, too, the prototype can only link between doc pages. So, we'll need further work to adapt the other links on the Qubes OS homepage like the links on the top bar, especially "INTRO" and "DOWNLOADS". What do you think about it? |
A few minutes ago, I fixed a bug in my mechanism, concerning handling the root directory. I also extended the example upto the root directory.
The more I think about it the easier is that work. My linked switch mechanism works as long as every name in the root directory namespace is either
Okay, this is irrelevant for this issue here, since this is not part of the language switch mechanism but part of how to translate links. Edit: I think the reason for absolute paths is correct redirection etc. Moreover, the localized warning message is a solution for #2932. |
I've revised my prototype. This includes
See this version. |
Concerning the number of provided translation languages: Maybe it's beneficial if we don't show a language in the switch until a certain group of pages has been translated fully or at least sufficiently in that language, e.g. home page, intro, download, getting-started, backup etc.. The reason for this consideration is that a hopeful click to your mother tongue could lead to great disappointment if the page is not really translated yet and thus hard to understand. Whether a language shall be listed in the switch or not can be controlled via a simple flag in a YAML file containing data about translation languages. So, the open question is: Which pages should be translated before releasing a language in the switch? Any other opinions or ideas? |
I'd say main page + some basic pages reachable directly from there, for example:
What about doc index? I guess it needs to be translated too, right? Or is it possible to extract translated titles from translated pages itself? |
Yes,
I had this idea, too. But even in the current version, the titles shown on the |
I'm slightly worried about people assuming translation status based on page title being translated in the index. It can be misleading in both ways (having untranslated title for translated page and translated title for untranslated page). |
Okay, I see. Just to make sure: Do you mean with "title" an item string on the doc index page? If yes, we could add a translation convention especially for the doc index:
|
I would add the support page and the FAQ page since they might be helpful for the user when experiencing problems: I would also add the pages all translators will probably visit:
The reasons are similar to the reasons why Assembly languages were invented: They're easier to write and much less error-prone than machine code languages. It's like making translation processes self-reinforcing. |
FYI, for #5308, we're planning to add release numbers to documentation page URLs, e.g.:
Since the localization effort is concerned with URLs, I want to make sure we coordinate this change with you. Do you foresee any problems? |
@andrewdavidwong commented on 10. Sept. 2019, 05:58 MESZ:
Thank you for involving us! Here are my questions: What will the permalink definitions in In this post, I proposed to collect all permalinks (defined in the YAML front matters) used by the website. Is there a way to do so without the need for permalinks in YAML front matters? For example, is there a way to find out the URL paths of the last Jekyll output? (I just quickly consulted the internet unsuccessfully.) The language switch in its most recent proposed version assumes that each URL path of an original MD file and the URL path of its translated file will only differ in their prefix, which is a language code only in case of the translated file. So, if we have the possibility and permission to specify the adapted permalinks in the translated files (which is breaking the rule number 1, in a sense) then it's fine. (Redirects etc. should also be adapted.) Since you plan to redefine the URL paths in the website repos anyway: What about adding a literal |
It's in flux, but I'm currently thinking:
with release-specified subdirectories, which would result in URLs like this:
In principle, yes, using Jekyll variables, e.g.,
That is possible. However, it would be preferable to add those just in the
which would result in URLs like this for all pages (not just doc pages):
|
Note: This may be relevant to QubesOS/qubes-issues#2930
[Branched from #2652.]
Implement a language switching mechanism on the website (highly non-trivial, since we can't use Jekyll plugins).
The text was updated successfully, but these errors were encountered: