<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Ted,<div class=""><br class=""></div><div class=""><div>It’s possible to scan the site map and copy the English version to corresponding location. There’s a Jekyll plugin can do that <a href="https://github.com/untra/polyglot" class="">https://github.com/untra/polyglot</a>. But I think we can just simple copy the new English page/post markdown source to each language’s folder in the beginning.</div><div><br class=""></div><div>John </div><div><blockquote type="cite" class=""><div dir="auto" class=""><blockquote type="cite" class=""><div class=""><div class=""></div></div></blockquote></div></blockquote></div><div><blockquote type="cite" class=""><div class="">On Jan 20, 2016, at 2:07 PM, Ted kremenek <<a href="mailto:kremenek@apple.com" class="">kremenek@apple.com</a>> wrote:</div><div class=""><div dir="auto" class=""><div class=""><br class="">On Jan 18, 2016, at 7:42 PM, John Lin <<a href="mailto:johnlinvc@gmail.com" class="">johnlinvc@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">Hi Ted,<div class=""><div class=""><br class=""></div><div class="">I think one of the advantages of using folders is that if a new page haven’t been translated yet, we can show English version as fallback . If we use git branches, It’ll be hard to do that in Jekyll. </div></div></div></blockquote><div class=""><br class=""></div><div class="">Indeed. I was thinking multiple folders myself.</div><div class=""><br class=""></div><div class="">I'm not understand the "show English version as fallback" part. If we used separate folders, I suspect we would just have subfolders for each translation, and a different URL for each translation. How would you expect the fallback to work? Have the web server redirects based on the URL to the English version, presuming it exists?</div><br class=""></div></div></blockquote></div><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Default English sounds reasonable. Even if we choose language by browser preference, we still need to provide links to translations for safe. </div><div class=""><div class=""><br class=""></div><div class="">Best,</div><div class="">John</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Makes sense.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 18, 2016, at 2:06 PM, Ted kremenek <<a href="mailto:kremenek@apple.com" class="">kremenek@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class=""><div class="">Hi John,</div><div class=""><br class=""></div><div class="">I'm re-confirming any legal questions, but the idea all along was to make the website material both publicly available but also open for the community to help curate. The material for the website is currently hosted on GitHub in a private repository, which we can easily open up.</div><div class=""><br class=""></div><div class="">The material for the website itself is written in Markdown, and we use Jekyll to generate static HTML content. There is a variety of ways we can handle hosting multiple translations. One model that was proposed to me is that we can have git branches with different translations, although I'm not certain if that would be a useful model. We obviously could have parallel folders as well to host different translations.</div></div><div class=""><br class=""></div><div class="">There's also the question of how we allow users to select a language on the website. Perhaps we would want to the most-likely language choice based on browser preferences, but I'm not sure. Maybe it's simple to just default to English, make it obvious on the landing page that alternate translations are available, and then allow them to select that to get a different URL that indicates the rest of the content is a different translation.</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class="">Ted</div><div class=""><br class=""></div><div class="">On Jan 16, 2016, at 11:33 PM, John Lin <<a href="mailto:johnlinvc@gmail.com" class="">johnlinvc@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">Hi Ted,<div class=""><br class=""></div><div class=""><a href="http://swift.org/" class="">Swift.org</a> has updated several times since I started the translation. The part that changes most frequently is the download page. I’ve made a script to auto update these download links. For other text updates, whenever I translate a page, I alway keep the origin English copy so that I can track the changes in the future.</div><div class=""><br class=""></div><div class="">I think keeping the translation up-to-date will be easier if the site's source is open. Currently I use page2rss & IFTTT to get notifications about changes, but if the source is open, we can track these changes on GitHub.</div><div class=""><br class=""></div><div class="">I’m more than happy to contribute these translations back to <a href="http://swift.org/" class="">Swift.org</a>, but maybe the site structure will need some changes to accommodate translations in various languages.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">John</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 16, 2016, at 3:56 PM, Ted kremenek <<a href="mailto:kremenek@apple.com" class="">kremenek@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class="">Hi John,</div><div class=""><br class=""></div><div class="">I think we would be open to having the community help host translations on <a href="http://swift.org/" class="">Swift.org</a>. My primary concern is maintenance. The material on the site will continue to evolve. What did you have in mind in terms of keeping the translation up-to-date?</div><div class=""><br class=""></div><div class="">Note if the translation was on <a href="http://swift.org/" class="">Swift.org</a>, from a legal perspective we'd consider it to be an open source contribution. The website material is hosted on GitHub. We were planning on opening it up once a few more logistical rollout issues were settled.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Ted</div><div class=""><br class="">On Jan 11, 2016, at 9:45 PM, John Lin via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">Hi<div class=""><br class=""></div><div class="">I’m working on a traditional Chinese translation of <a href="http://swift.org/" class="">Swift.org</a></div><div class=""><a href="https://swiftlang.tw/" class="">https://swiftlang.tw</a></div><div class=""><br class=""></div><div class="">First, will there be any legal issue?</div><div class="">Second, is it possible to add the translation to the official <a href="http://swift.org/" class="">Swift.org</a> ?</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class="">John Lin</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=cUTXn2XUQg0NGOEWHTVTyDr9W6Is2djHPo9bUJUJ-2FRajvqjdmJS308PABePUF0-2BuWIZUzkbh6o3vmV6sCYCydWnyfanp8GUEJFe-2Bueh2mGU2VhsgKzXWZxYF8SGDVfbzjMtNzNt2A34fvQ4k-2F7keh6jpihUbAYblNLz8UGaOgCHK13yaFIpW-2BYD7myOEqlAtvQ4yHiOdghObDrnm80v6p3J6z91-2BWZjQVy5P-2BvhX8Vw-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-dev mailing list</span><br class=""><span class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></blockquote></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div></div></blockquote></div><br class=""></div></body></html>