Op 9 sep. 2016 14:51 schreef "DC*" <[email protected]>: > > 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.
Unless they arrive from Google or other search engines able to serve localized versions of the same page. That requires just a few additional metadata tags that link the related pages and declare their language, and the appropriate use of the hreflang attribute. Both can be automated AFAIK. The landing page can default to English, with some JavaScript magic to ask the user for their preferences (if locale is not english) or even auto-redirect. Other arrivals would require manual intervention from the user, but that should be a small percentage of visitors. > 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 < > [email protected]> 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 <[email protected]> > > > wrote: > > > > > > > > > > > On Thu, Sep 8, 2016 7:21 AM, Steve Dougherty [email protected] > > > > 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: [email protected] > > > > _______________________________________________ > > > > Devl mailing list > > > > [email protected] > > > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > _______________________________________________ > > > Devl mailing list > > > [email protected] > > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > _______________________________________________ > > Devl mailing list > > [email protected] > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > _______________________________________________ > Devl mailing list > [email protected] > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl _______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
