Translate website to Portuguese

[huey735]

Create duplicates of: /_data/ dao_content.yml main_nav.yml /_includes/ footer.html homepage_content.html main_nav.html os_selector_options.html Add the "_tr" suffix to signal that they're the translated versions and adapt the files inside /_includes/ to link the translated pages and strings.

Add pt_PT.yml inside /_data/ with the translated strings from .html files.

Change functions in /_layouts/default.html to accommodate for new languages. Add "ref", "lang" and "language" variables to the web pages to be translated and copy them into a folder named after the respective language's code (the same specified in "lang") : /community.md /dao.html /downloads.html /faq.html /index.md /markets.html /stats.html /vision.md

Copy also /images/DAO and re-render the images with the translated strings.

[m52go]

Hi @huey735, sorry for the delay...I've been traveling and I'm on holiday this upcoming week. I've cloned your repository and will check it out as I can.

For now, two small things:

1. could we change the pt_PT directory to just pt? I think it would help URLs would look cleaner.
2. do we want to keep URLs in English? I thought we discussed that on the last translator call, but I can't remember.

[huey735]

1. I used this standard for localization as we have Portuguese from Portugal(pt_PT) and Portuguese from Brazil (pt_BR). What standard do you suggest we use?
2. We agreed to translate them. But "downloads" and "index" should be exceptions due to how their linked.

[huey735]

@erciccione due to Jekyll (or my understand of it) certain files need to stay on certain folders so I figured it'd be better to keep them next to original and just add the suffix "_tr" to highlight that they're the translated versions. And these files won't relate to a single language. The "_tr" files inside /_data will include all the translations for each language each and those inside /_includes will have the English text replaced with Liquid tags pointing them to the respective .yml language file inside /_data. And this is just for the .html and .yml files. There will still exist language folders in the root for each language. Inside them you'll find the copy of the translated files and images. This isn't up to date but it may give you a sense of the architecture I had in mind - https://github.com/huey735/huey735.github.io

I'm still learning Jekyll and Liquid and I followed this suggested method - sylvaindurand.org/making-jekyll-multilingual/. It seems less intrusive than other methods available for translation. I've been looking at them and maybe in the future with a reconstruction of the website other methods will be more appropriate.

I think they should be kept in english. Maybe we should have a vote on this. I think this has gone back and forward a couple times.

[m52go]

Looks good to me overall. My biggest concern remains long-term maintainability, but I think that can only be rectified by formatting all website content in markdown instead of HTML (e.g., that's how the plugin @erciccione suggested seems to work).

better use pt_PT, it's a better standard and avoid problems in the future

Understood...I didn't realize some languages will need more than one option. Could we turn the underscore into a dash (e.g., pt_PT to pt-PT)? I think it looks a lot cleaner, and the vast majority of our URLs and redirects use dashes.

do we want to keep URLs in English?

I went back and checked the call...looks like we agreed to keep URLs in English? See this clip from the last translator call:

https://youtu.be/K1TG-_ISj2w?t=2220

Looking at other sites, that seems to be the standard. It also seems more intuitive to me.

[huey735]

Could we turn the underscore into a dash

Sure

[m52go]

@huey735 looks good. I just resolved a merge conflict related to the software release from yesterday.

One item: I noticed in two places there's a Front Matter attribute ref with the value donwloads. Is that a mistake?

[m52go]

@huey735 for future reference...GitHub does weird things when the name of the branch you want to merge is also called master (case in point: here's my commit that fixed the merge conflict...only made one small change, but there's a lot more there that's unrelated to this PR).

Next time please call your forked branch something other than master 🙂

[huey735]

@m52go can you point me to these front matters? Sorry for the poor naming of the branch.

[m52go]

@huey735 just added comments. I didn't fix myself because I wasn't sure if they were connected to something else.

[m52go]

ACK