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

Make the site multi-language #6

Open
ilg-ul opened this issue Aug 14, 2016 · 16 comments
Open

Make the site multi-language #6

ilg-ul opened this issue Aug 14, 2016 · 16 comments
Assignees

Comments

@ilg-ul
Copy link
Contributor

ilg-ul commented Aug 14, 2016

Two issues anticipated:

  • selection of a multi-language gem
  • definition of a folder structure to store the different language pages
@ilg-ul ilg-ul self-assigned this Aug 14, 2016
@ilg-ul
Copy link
Contributor Author

ilg-ul commented Aug 15, 2016

Question:

  • do you plan to use Brazilian Portuguese or Portuguese for your translated pages? In other words, the language id will be pt_br or pt?

@ilg-ul
Copy link
Contributor Author

ilg-ul commented Aug 15, 2016

I am collecting some links to Jekyll multi-lingual solutions:

Ruby gems/plug-ins:

@carlosdelfino
Copy link
Contributor

Well due to the new orthographic agreement of the Portuguese language and the political project of unification of the language, I suggest keeping only PT, since technically it is perfectly possible to consolidate the work only in PT. Even knowing that in colloquial language there are several slang that differ between countries.

Thus we consolidated the translation efforts. The result will be the same and readable at all, mainly because our intention is a purely technical material.

If someone who has mastered the Portuguese language in its original form from Portugal to come to join us wants to express contrary opnion assess the impact and ramificamos, if it is really necessary to have two translation branches, PT and pt_BR.

For now I reaffirm that prefer only one, PT.

See the example of Stackoverflow Portuguese, it works perfectly for both variants.

@carlosdelfino
Copy link
Contributor

I'm reading the suggested links and liked the first because of the argument that advocates no internal interference in Jekyll even with plugins.

I think the proposal to have a code in the layout format the site very attractive bilingual form, but the ideal is to have the url any indication of the language beyond words natively as there could be conflicts, as some terms will not be translated.

One way or another, or the path of the url should indicate the language, or the file, I prefer to be the directory to have a proper separation of files in the source.

@ilg-ul
Copy link
Contributor Author

ilg-ul commented Aug 15, 2016

I suggest keeping only PT

ok.

so I suggest we have the Portuguese pages marked with lang: pt, and have the permalinks prefixed with /pt/.

I don't think we should translate the urls, they can remain in English; the prefix should be enough to differentiate the pages.

@ilg-ul
Copy link
Contributor Author

ilg-ul commented Aug 15, 2016

for start, I would add lang: en to all existing pages.

@ilg-ul
Copy link
Contributor Author

ilg-ul commented Aug 15, 2016

since the actual site structure is explicitly defined by the permalinks, the physical folder structure of this project is not relevant, we can adopt any scheme that suits us and we can change it at any time.

for example we can start with minimal changes, by storing the Portuguese manual pages in the same folder as the English ones, and insert .pt. in the name, for example basic-concepts.pt.md.

this does not require any plug-in, and we can use it immediately.

@ilg-ul
Copy link
Contributor Author

ilg-ul commented Aug 15, 2016

Sidebar

for a completely translated site, we should think of translating the sidebar too, but, for the beginning, I think we can live with an {% if page.lang == 'pt' %} in _include/content/sidebar.markdown and you can provide the translation for the chapter names there, if you think necessary.

@carlosdelfino
Copy link
Contributor

Well, I agree with everything.

I think for the layout (_layout and _Include) of the site and the pages of the site structure, not the content itself, we can use a file in the folder _data for translation, so we will not have problems, also remember to add the charset UTF 8 as standard, but when someone is translating into a language that utf-8 does not meet this may change in the future and adjust the layout to suit every charset.

As suggested in https://www.sylvaindurand.org/making-jekyll-multilingual/

@carlosdelfino
Copy link
Contributor

Please see #9

@ilg-ul
Copy link
Contributor Author

ilg-ul commented Aug 15, 2016

please check http://micro-os-plus.github.io/pt/user-manual/

@ilg-ul
Copy link
Contributor Author

ilg-ul commented Aug 15, 2016

remember to add the charset UTF 8 as standard

there is a encoding: utf-8 definition in _config.yml. do we need anything else?

@ilg-ul
Copy link
Contributor Author

ilg-ul commented Aug 15, 2016

the folder _data for translation

yes, we can use this, if necessary.

there are many other suggestions in Sylvain's post. if you think they are needed, please suggest punctual changes, the current proposal is very basic.

@ilg-ul
Copy link
Contributor Author

ilg-ul commented Aug 15, 2016

I added the language ID to the <html lang="xx"> element.

@ilg-ul
Copy link
Contributor Author

ilg-ul commented Aug 15, 2016

I translated the 'Contents' label used by the TOC generator.

the translation is done via a data file (_data/i18n.yml), update it if necessary.

@carlosdelfino
Copy link
Contributor

Mãos a Obra! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants