Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Received-SPF: pass (nike.apache.org: domain of kay.schenk@gmail.com designates
 209.85.192.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAP-ksohCn3SmW_ajP11wvv6tApDNkrmiJOBR56GwEeWd8+5Hpg@mail.gmail.com>
References: 
 <CAP-ksohCn3SmW_ajP11wvv6tApDNkrmiJOBR56GwEeWd8+5Hpg@mail.gmail.com>
Date: Fri, 23 Aug 2013 14:29:38 -0700
Message-ID: 
 <CAGj32147WfLv9z13w+LTewduft+ZtoDpAznEMLuo3edtUgycMQ@mail.gmail.com>
Subject: Re: Brainstorming: Can we refactor the website to make translation
 easier?
From: Kay Schenk <kay.schenk@gmail.com>
To: devAOO <dev@openoffice.apache.org>
Content-Type: multipart/alternative; boundary=e89a8ff1ca78976eec04e4a41aeb

--e89a8ff1ca78976eec04e4a41aeb
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Aug 23, 2013 at 8:58 AM, Rob Weir <robweir@apache.org> wrote:

> (Responses to dev@openoffice.apache.org, please)
>
> Obviously our website is quite large.  Google reports 21207 pages
> indexed in the www subdomain, and a further 48075 pages in the wiki
> subdomain.   But for purpose of this post, when I talk about the "home
> page" I'm talking about the contents of our main index.html and the
> most commonly visited pages directly linked to it, e.g., the
> why/download/product/get-involved, etc. pages.
>
> This core homepage content amounts to around 25 pages.
>
> Today this content is scattered around the content tree.  Some of it
> is in the root.  Some of it in /why and /download directories.  Some
> of it is template-related and is in /templates rather than in
> /content.
>
> As a test I tried to create my own NL page, in the fictitious "xx"
> locale.  You can see it here:  http://www.openoffice.org/xx/
>
> It is not working correctly, but it already required a lot of
> non-trivial hacking:
>
> 1) I had to hunt around and guess which files to copy.  Do I copy
> scripts, images and CSS, or just content pages?   Some of the
> directories had out-dated content that was not linked to my anyone.
> It was hard to figure out what the minimum amount of content needed
> was, and where it was located.
>
> 2) The main index.html file had to be edited to refer to CSS in the
> root, rather than current directory
>

Some of what you are experiencing re the css issues are due to many
migrations and css that applies ONLY to the home page and not others.
There's no reason why this should be this way really. SOme of us dealing
with this on a day to day basis knew this but were afraid to mess with it.


>
> 3)  Download page is missed up, missing CSS and/or scripts.
> Presumably I need to copy something into the xx/download dir, or edit
> scripts to make them refer /download off the root.
>
> 4) The /xx/why pages are not showing the right side navigation now.  I
> must have missed something there as well.
>

hmmm...not seeing what you've done, this could be do to some  CMS setup.


> Of course, I could figure the above out eventually.  It just requires
> some time and effort and trial and error.  But none of this is
> documented, and even if it were this is a fragile approach and
> probably beyond th web development skills of a typical translator.
>
> But we do know this has been done for some languages.  They got it to
> work.  The German page is a good example:
>
> http://www.openoffice.org/de/
>
> Now this looks good, but it is still a messy thing from a maintenance
> perspective.  If we make structural changes to the main English page,
> then those changes need to be manually merged into to every NL page.
>
> What can we do to improve this?
>
> Here's my idea:
>
> 1) What if we refactored the home page so it was all self-contained
> into these directories:   /scripts,  /styles,  /images and /en/?
>
> 2) Make the /en directory be pure content.  Only the stuff that needs
> to be translated.  It loads everything else, scripts, images, etc.,
> via URLs relative to the root, e.g.., in /scripts, /styles, etc.
>
> 3) Reduce or eliminate any embedded Javascript within pages.


I didn't think we had a lot of this but maybe more than we should.


>  For
> example, refactor the code in download/index.html so it is external
> and depends on JSON resource files for translated strings.  Aim so
> translators never need to touch script.
>

Well I don't really know JSON so I can't speak to this. Will investigate.
though we do/did make extensive use of JS data structures in the past.


> 4) Ultimate goal is for someone to be able to jump start a new NL home
> page by simply requesting an svn copy of the /en directory, and then
> editing the resulting files.  No one should ever need to do what I'm
> doing with the "xx" pages.
>

I think once upon a time -- maybe LONG ago -- the NL pages were
standardized to be clone of the main index page. But, various NL groups
wanted more of their own identity, and so we have what we have.


>
> 5) Maintenance is far easier.  Most things like changing the scripts,
> is done in one place only.  But even changes to the HTML are easier.
> Since we then have a common branch point via the svn copy, when
> structural changes are added to the main /en HTML, these can be merged
> in more elegantly to the translated versions, using Subversion.
>
> 6) Via Apache redirects we can ensure that the default call to
> www.openoffice.org/ goes to /en/.  Conceivably we could also do locale
> detection and send requests automatically to the appropriate NL home
> page.
>
> A variation on the above would be to use Pootle, rather than svn
> copy/merge to maintain the translations.  But that would require the
> same refactoring work to enable it.  And it would require further
> investigation to identify a way of extracting and merging translation
> strings in MDText files as well as (X)HTML files.
>
> This is obviously more than a one-person task.  So I'd be interested
> in hearing what you think in general about this approach, whether
> there is a simpler alternative I've missed, and whether this is
> something you'd be interested in helping with.
>
> Regards,
>
> -Rob
>

I think most of the ideas are good as long as we don't introduce
technologies into the web site that down the road would require anyone to
know, or deal with, much more than basic HTML and JS. This has been a
factor in maintenance in the past.  Even the complicated JS introduced in
one the last revisions to the home page was really more complex than what
we needed as far as I was concerned -- we're talking maybe 2006 here.

I guess those of us interested can take a look at what you've started in
"xx".


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


-- 
-------------------------------------------------------------------------------------------------
MzK

"When in doubt, cop an attitude."
                -- Cat laws

--e89a8ff1ca78976eec04e4a41aeb--