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-jekyll-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
