Didn't know Google would do that. That's actually quite good as would serve users with the appropiate content without any intervention server or client side from our part.
I would not add any JavaScript prompting or redirecting users at all, I'd rather just have a language selection menu/dropdown, less invasive and friendlier in general, IMO. On Fri, Sep 9, 2016 at 4:21 PM Bert Massop <[email protected]> wrote: > 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 _______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
