Uh oh!
There was an error while loading. Please reload this page.
i18n/build improvements, part 1 - #243
Conversation
snostorm
commented
Feb 26, 2015
@iojs/website can we get a faster review on this? Because of the mass changes to (That said, if there are real blockers on this change, we should properly deal with them first.) |
bnb
commented
Feb 26, 2015
Went through everything, and it beside my previous comment, it looks good to me. |
snostorm
commented
Feb 26, 2015
Yup @bnb, once that we have this merged it would be trivial to follow up with another PR adding support. |
therebelrobot
commented
Feb 26, 2015
+1 |
snostorm
commented
Feb 26, 2015
Forgetting our own rules. How many +1's do we need before somebody hits the big green button? |
therebelrobot
commented
Feb 26, 2015
Oh, yeah, I probably could just merge it. sorry. |
i18n/build improvements, part 1
snostorm
commented
Feb 26, 2015
Merci beaucoup @therebelrobot! Next up: trying to work some JS magic around language detection. (Although we may need some hints from the server to help it work better.) |
bnb
commented
Feb 26, 2015
@snostorm Don't know if you saw it, but someone suggested doing it by geo-ip (or whatever geological ip location is called). I think it was in one of the last few TC meetings that someone, maybe @mikeal, said it was super annoying to have pages auto-translated in foreign countries with no way to easily change back to English. Additionally, @mikeal said some of the localization groups don't want their translations to be automatically changed, as the majority of developers in their country/lang read and use English commonly or for development. They only want their translation as a backup. Back to geo-ip, we could auto translate by ip for the localization groups that want that. I would use some notifications library (there are about a million jQuery plugins for this) and simply put a toast/notification in one of the corners that had a description in both languages and link to the English translation that went away when the user either went to the English translation or closed it. We could do the reverse for the languages that want to keep English as the main site, with a description in both languages and a link to the correct language translation. Thoughts? |
therebelrobot
commented
Feb 26, 2015
I like the idea, @bnb, I also have a few open APIs that do geo-location that we could ping on page load, then just have a list of what the localization team wants for their region. We'd have to get all those regions specified, of course, maybe through geoJSON, but should be fairly simple. |
Fishrock123
commented
Feb 26, 2015
I'm getting an error at https://github.com/iojs/website/blob/master/gulp/tasks/templates.js#L59 when trying to rebuild after bumping the versions for the release. Investigating. |
Fishrock123
commented
Feb 26, 2015
Error log: |
therebelrobot
commented
Feb 26, 2015
Kk. Looking into it too. |
therebelrobot
commented
Feb 26, 2015
Kk. The issue was with the |
snostorm
commented
Feb 27, 2015
Re: auto-language, I was thinking of doing it in a few passive ways (to start):
Mostly we're not even linking to the translations right now, so Google has no reason to find them. I want to resolve that in Part 2 (or 3) as well. |
snostorm
commented
Feb 27, 2015
Also: lets move back discussion to one of the generic Issues to not lose track of good ideas :) |
Modifies to use handlebars, only adds checksums/git info to changed files, outputs only changed files.
Semi work-in-progress, but merge-able.
./publicfiles (that haven't actually changes) which I reported as a side comment in Updates public/ with out-of-date i18n #234i18n-*hooks in the existing template file to keep the diff of./publicmore readable and left it as a final commit for diff readability (when reading the individual commit changes.)