htdocs/, www.gnucash.org and translation

[Derek Atkins]

Josh Sled <jsled at asynchronous.org> writes:

> There's been a loose decision to continue on with the gettext-based
> translation, but in a modified form.  As per cstim's comments in
> http://svn.gnucash.org/trac/changeset/13914 , it doesn't really work to
> translate a website on a sentence-by-sentence basis.  At the same time,
> it's pretty sensible to have the chrome, navigation and overall
> structure be shared (i.e., identical) between the translations.

I think it would be better to consider a paragraph-by-paragraph
translation instead of "full page" translation. Obviously
sentence-by-sentence is way too hard for the translators, and way too
granular, but there's a trade off..  If the main english content of
the site gets updated -- let's say a single word gets changed -- how
much of the translated website should get "untranslated" due to the
single word change of the source?

If we translate whole-pages, then a single change to the source will
cause the WHOLE resulting page to lose its translation.  Whereas a
paragraph-by-paragraph translation reduces the "failure" to a single
part of the page.

Having smaller chunks to translate also helps the translators localize
changes.  I think it would be much easier to respond to "Gee, I
noticed this particular paragraph isn't translated anymore, let me see
what changed there."  On the other hand, the whole page failing to
translate might make it much harder to figure out what actually
changed.

Keep in mind that the main website content /IS/ quazi-static.. It's
not expected to change often, so making it easy for the translators to
find "broken" sections is probably the optimazation we want.

Granted, you can always look at the diffs and changesets to figure it
out, but do we really expect our translators to be following the
gnucash-changes list or really understand the source control system
enough to figure out what changed?

[snip]
> In this way, the bulk of the site is identical for each translation, and
> a conventional short-string translation effort can get an interesting
> level of the website translated.  But at the same time, the translator
> has the flexibility needed, even to the level of structuring the page
> differently, adding sections not present in the default language, using
> different images, &c.

Well, it can handle the navigation, but none of the content.  I'm
worried that in this method we'll wind up in a state where different
languages truly have different content, so we don't have a
"translated" website but rather we have multiple websites in different
languages that just happen to have the same chrome.  Is that really
what we want?

I admit that the concept of using different images might be
interesting, but honestly right now we don't have many images on the
website.  Most of the images are in the docs, which aren't part of the
website effort.

Just my $.02, after working a bit on the site and trying to handle
news translation.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available