htdocs and the newest news.

Sat Feb 11 11:28:46 EST 2006

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.

> > Judging by how programs get translated, I'd say partial is not as
> > bad to the users as we may like to think. Lots and lots of
> > translated programs have only a fraction of the total number of
> > messages translated. As long as certain critical areas are covered,
> > many users seem happy with partial. The existing wiki translation
> > help can guide others in how to add more translated messages.
>
> A website != a program.

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 wish I knew more about generalized international website
> development.  There's got to be some "standard" way
> internationalization is done with quazi-static content.  I honestly
> don't think most sites use gettext() for the main pages.

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.

It's not an easy problem and it is ALWAYS characterised by massive amounts of 
partial translation. (Along with a lot of companies that offer to translate 
and localise for pots of cash.) The automated translations don't look good to 
native speakers.

It comes down to this:

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'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.

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 also convinced that in our field, accuracy is more important so that if 
part of the site has to be updated, I think it is far more useful to everyone 
for that change to be disseminated automatically to ALL visitors to the site, 
even if the change is initially presented in English.

> > I'm sure someone will volunteer in time - after all that's how we have
> > the current mix. Having a POT file may help as it's easier to handle than
> > the previous format. We can ask the GNU Translation Project.
>
> Perhaps we should ask on gnucash-user?

Will do.

> > The Wiki, however, is a lot easier for people to amend and if
> > someone wants to add a translation of an existing page, they
> > can. It's just not transparent as if the site was to detect the
> > language from the browser, as the main site now does.
>
> It's easy to amend, yes, but how can we get wiki.gnucash.org to also
> provide a German interface, a Spanish interface, etc?  Clearly it's
> somewhat possible, wikipedia does it..  But I have no idea how to set
> that up for us.

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

> > I guess the answer to both is a decent syntax highlighting editor. I
> > use gedit for php and html - bluefish is good too, as it Kate, or my
> > old stalwart, vi.  ;-)
>
> 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 (.

> Right, which makes the website accessibility even MORE imporant!  The
> website is what entices the user to download the program.  It NEEDS to
> be there.
>
> Speaking of which, we're already getting requests for 1.9 screenshots!

(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.

> PS: It sounds like Linas is going to update the website to pull from
> SVN on MONDAY.  So we should have most stuff "solved" by then.  ;)

OK.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060211/33e237c1/attachment.bin