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/
pgprxsXIHAFun.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
