Am 08/23/2013 05:58 PM, schrieb Rob Weir:
(Responses to d...@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
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.
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/?
Do you mean to centralize all kind of files that are shared? Like button
pics, download scripting, color definitions?
I thought about this already for the download area as then these files
are all in a single location. But of course it's also possible to do
this for the entire wesite.
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.
Should the "en/" folder have another purpose than just to work as a big
template?
3) Reduce or eliminate any embedded Javascript within pages. 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.
At least for the download webpage I thought, too, already to separate
code and text because it makes it easier for other people to use the
design of the main download webapge for their language.
I've not yet committed anything but the idea is to separate a) HTML
design, b) JS code and c) translate-able text strings from each other.
However, I put already a Todo note into the Wiki (see the 2nd row from top):
https://cwiki.apache.org/confluence/display/OOOUSERS/Improvements+for+the+download+webpages#Improvementsforthedownloadwebpages-ImmediateConcerns%2CShort%2FMidTermImprovements
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.
Yeah, indeed a hugh work to get to this dream.
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.
I think it's no secret when I tell you that this is a great idea from
the view point of maintenance and to attrack new volunteers for not yet
known and supported languages.
However, I'm really wondering if this will be a success as it would mean
nothing less than a complete rebuild of all files on the entire website.
I believe it's better to split this up into some chunks. What's the most
interesting ansd important part of our website? Start with this, build
up some skills, knowledge and best pratices and then enroll it more and
more over the remaining parts - and hopefully with more volunteers. ;-)
My 2 ct.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscr...@openoffice.apache.org
For additional commands, e-mail: l10n-h...@openoffice.apache.org
