htdocs and the newest news.

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

> On Saturday 11 February 2006 2:36 pm, Derek Atkins wrote:
>> Let me be more explicit.  I'm worried about someone finding a spelling
>> error, or making what would be a minor edit to a paragraph, and that
>> edit causing all translation to fail because the strings no longer
>> match.
>
> No. Only the translation of that specific paragraph (or more likely specific 
> sentence) would be affected. All other translated text would remain. I can 
> see no way of automating this. The site cannot auto-translate and if the 
> strings don't match, the single unmatched string must be shown in the 
> original language. It's identical to gettext behaviour in programmes.

Yea, but it seems strange (to me) to go to e.g. a spanish page and see:

Español...Español...Español...Español...Español...Español...Español...
Español...Español...Español...Español...Español...Español...Español...
  English... English... English... English... English... English... 
Español...Español...Español...Español...Español...Español...Español...
Español...Español...Español...Español...Español...Español...Español...
Español...Español...Español...Español...Español...Español...Español...

> Yes, I realise that. The strings tend to be longer, the frequency of changes 
> much lower. However, I do feel that users are much less bothered by partial 
> translations than you would fear.

I don't know how much users are bothered..  I do agree that the
strings tend to be longer and changed less frequently.

> How many sites are actually translated? The old method of separate
> directories led to huge inconsistencies in the different sites and
> still left large sections untranslated.

Depends on your definition to "translated".  To me, as a user, a
translated site is one where I click on an icon (usually a flag,
but sometimes a country name) and see the site in that language.
As a user I don't particularly care how that happens.

As a developer, I want to make the process as simple and
straightforward as possible, and try not to overload the poor
webserver.  It seems rather silly to execute PHP and translate the
content on every page-grab.  It would seem much more
processor-friendly to have the content be quazi-static and just have
the webserver combine the multiple quazi-static page-parts into the
page presented by the user.

Keep in mind that www.gnucash.org is a rather old, overutilized
machine.  So, yes, CPU usage per-page is definitely an issue to think
about.

> Do we want, either:
>
> A) Accurate content and incomplete translation
>
> OR
>
> B) Complete translation and out-of-date content.
>
> I don't think anyone can create a system that provides both.

I certainly agree with this statement.

> I've always thought centralised translation is the best approach -
> have ALL content strings ACCURATE and then translate them. This
> leads to a lag time before new strings are translated BUT,
> crucially, out-of-date strings are binned from all translations
> immediately and replaced with content that is at least accurate, if
> not translated. This is the gettext behaviour and is instantly
> familiar from other gettext implementations.

> The old site prioritised translations above accuracy. Easiest
> example there is the move from CVS to SVN.

True, but sed -i -e 's/CVS/SVN/g' `find . -type f` would solve that
problem...  To some extent.

> With gettext, every translated site would have shown the SVN instructions 
> immediately the core strings changed. OK, these would initially appear in 
> English in each translation but which is preferable? To have text that is 
> misleading but translated or text that is accurate but not translated?
>
> I'm convinced that we cannot have both.

I'm not sure.

> MediaWiki separates all it's own strings into Language.php which contains 
> arrays of strings. MediaWiki supports localisation but does not directly 
> support internationalisation. i.e. you must reimplement the entire site with 
> a new Language.php to have a second language available for the MediaWiki 
> strings. This is total_site_size = one_site_size * number_of_languages.
> Probably best done with subdomains.
> http://meta.wikimedia.org/wiki/Documentation:Administration#Localization
>
> As for the content, I can't find any reference to translating the content of 
> MediaWiki sites into multiple languages per site, i.e. i18n. Being a wiki, 
> the strings in Language.php can be edited in the wiki itself but only by 
> admins - one per site. Further development of i18n is still only in the 
> planning stage:
> http://meta.wikimedia.org/wiki/Interface_translations_wiki

It's the content that interests me..  As we're moving most of the
content from www.gnucash.org into the wiki, it would seem to imply
that we want to have the wiki content internationalized too, right?

>> See, I use emacs which makes paren-highlighting very easy..  Every
>> time you hit right-paren it shows you the corresponding left-paren.
>
> I have that too, but it doesn't seem to work with scheme. There are always 
> more ) than (.

Then you type too many )'s ;)

> (Why is this all up to me? Does anyone have some ideas about what we want in 
> the Features pages?) I don't think I'm best placed to decide what we put up 
> there.

It's not all up to you..  But I think most people are waiting for you
to finalize the website format before they go make changes to the
content.

-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