Effectively Github does *not* support Content-negotiation. If we don't want
to adopt another strategy to serve pages we'll need to stay away from
Github Pages.
Otherwise we'll need to add links to access the site in different
languages. Thus serving content from URLs such
/{de,es,fr}/documentation.html or /documentation.html.{de,es,fr} (or
similar format).If we use localized URLs (which most static site generators do support) the user would require to switch languages manually. We'll need also to request changes to the designs to add a language selection menu/selector. On the other side, we gain in terms of cost (Github pages hosting doesn't cost us) and time (we don't need to configure, patch, upgrade any server). I think we're better off with this option as money is always a concern and should be carefully handled. Best regards, On Fri, Sep 9, 2016 at 5:43 AM Florent Daigniere < nextg...@freenetproject.org> wrote: > For l10n there are two different problems: > 1) getting the translation from the translators > > I don't know much about that part so I'll defer to those who know (I > think we use transifex). > > > 2) serving the right translation to the user > > The current website generates pages for all languages... and uses HTTP- > content-negotiation (MultiViews in apache terminology) to pick which > language to serve to the client. > > https://freenetproject.org/index.html > https://freenetproject.org/index.html.en > https://freenetproject.org/index.html.fr > > That works without javascript (it's done server-side) and is *very* SEO > friendly since only the first URL will be indexed (we serve a Link > header pointing there). > > I don't think that github pages supports it (but then again, I might be > wrong). If it doesn't, how are we going to do it? > > Regards, > Florent > > On Thu, 2016-09-08 at 18:43 +0000, DC* wrote: > > Hi everyone, > > > > I'm more concerned about translations and a clean and quick > > setup/deploy > > workflow rather than who would implement the design changes. > > > > Choosing the right tool for the job would make a huge difference for > > the > > developer who takes the job of implementing the new design. > > > > In that regard after taking a quick look at how Jekyll handles > > i18n/multilingual sites I'm not convinced it's the right tool; as > > translations are handled with 3rd party plugins rather than Jekyll > > itself. > > So it's not supported from the get-go. > > > > I've found another static site generator called Middleman[2] which > > does > > support i18n[3] without 3rd party code. I would evaluate how both > > tools > > handle a set up with Transifex before committing to anyone of those. > > > > Here[3] is also a review of various static site generators for > > reference. > > > > Best regards, > > > > [1] https://middlemanapp.com/ > > [2] https://middlemanapp.com/advanced/localization/ > > [3] > > https://www.smashingmagazine.com/2015/11/static-website-generators-je > > kyll-middleman-roots-hugo-review/ > > > > On Thu, Sep 8, 2016 at 12:24 PM Ian Clarke <i...@freenetproject.org> > > wrote: > > > > > > > > On Thu, Sep 8, 2016 7:21 AM, Steve Dougherty st...@asksteved.com > > > wrote:> What is your timeline for the whole site, or was two weeks > > > your > > > target? > > > We > > > > > > > > > > > have a massive amount of copy to rewrite (and translations to > > > > redo?), and > > > > > > > > > > > pages to restructure, or do you plan for us to get up and running > > > > with > > > the > > > > > > > > > > > old verbiage and gradually refine it? I do have some familiarity > > > > with > > > > > > > > > > > Jekyll but I have no experience with translating Jekyll sites, > > > > I'm > > > > > > > > > > > concerned about that. I do have a couple of ideas though. > > > > > > > > > > > > > > > I'd propose using the existing copy; anything else would introduce > > > more > > > > > > delay and cause the new site to launch with less translation > > > available. > > > > > > > > > > > > > > > While I want to get the new site launched ASAP, I have to disagree > > > on this > > > point. I think if we don't simplify the site significantly then it > > > will > > > negate > > > a lot of the benefit of the redesign. We can reintroduce content > > > over > > > time, but > > > should do it in a way that it keeps the site looking simple for > > > newbies > > > (while > > > allowing them to drill down to detail if they need it). > > > > > > > > > The community (and me because I get lots of source string > > > clarification > > > > > > questions) have put a lot of effort into the translations already. > > > The > > > > > > Spanish translations are complete; the French one has excellent > > > (82% > > > > > > website; 97% overall) coverage. > > > > > > > > > > > > > > > This is all very valuable, but it will be very limiting if we > > > require that > > > we > > > use all of that material on day-one of the new website. We should > > > launch > > > with > > > something simple, and then reintroduce this content over time, > > > being > > > careful to > > > keep the site looking clean and simple for new users. > > > We can keep the old site on an alternate domain so nothing is lost > > > - > > > perhaps > > > doing some kind of smart 404 redirect from the new site (although > > > I'm not > > > sure > > > if Jekyll has that flexibility - requires investigation). > > > > > > > > > Whatever technology we use - be it through you or someone for hire > > > - I'd > > > like to be sure it has support for localization in a way that makes > > > it > > > > > > easy for translators to contribute. Being a Ruby thing, it looks > > > like > > > > > > Jekyll uses YAML, which Transifex supports. Failing that, perhaps > > > one of > > > > > > the formats Pontoon supports? [1][2] > > > > > > > > > > > > > > > Agreed, I have limited experience with localization technologies, > > > but it > > > should > > > be a requirement for anyone that does the PSD -> Jekyll conversion > > > that we > > > support localization. > > > Ian. > > > Ian Clarke > > > Founder, The Freenet Project > > > Email: i...@freenetproject.org > > > _______________________________________________ > > > Devl mailing list > > > Devl@freenetproject.org > > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > _______________________________________________ > > Devl mailing list > > Devl@freenetproject.org > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
