On Fri, Aug 23, 2013 at 3:17 PM, Marcus (OOo) <[email protected]> wrote:
> Am 08/23/2013 05:58 PM, schrieb Rob Weir:
>
>> (Responses to [email protected], 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?
>
All the stuff that does not need language translation should be
shared. We're doing that in some cases. But our HTML pages are not
doing this right.
An easy example:
Our root index.html page uses external CSS files. Good. That's what
we should be doing. But the HTML file refers to them as:
@import "home.css";
@import "styles.css";
@import "exceptions.css";
But this breaks when we copy index.html into a new subdirectory. It
needs to then be something like:
@import url("../home.css");
@import url("../styles.css");
@import url("../exceptions.css");
or maybe:
@import url("http://www.openoffice.org/styles/home.css";);
@import url("http://www.openoffice.org/styles/styles.css";);
@import url("http://www.openoffice.org/styles/exceptions.css";);
So the task is really two things:
1) centralize the non-language resources
2) Change the HTML so it loads from the canonical locations rather
than assuming these files are in the same directory.
> 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?
>
I was thinking the en/ folder would be what we redirect
http://www.openoffice.org to show by default. So it would be the real
live home page.
>
>> 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
>
The /download page is the hard one. There is a lot going on there.
>
>> 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. ;-)
>
Take a look at what I put in "xx" directory:
https://svn.apache.org/repos/asf/openoffice/ooo-site/trunk/content/xx/
It is just the root index.html page, the download page and a handful
of others. I think it is 25 pages total. There might be others we
want to translate as well, but I think we can keep it to a reasonable
size. At some point, 3 or 4 levels deep in hyperlinks, the user will
end up in an English language page. But for the most-commonly used
pages, the ones that are 2 and 3 links from the home page, I think it
is a reasonable goal to translate those.
Regards,
-Rob
> My 2 ct.
>
> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
