Re: [libreoffice-l10n] Bavarian and Nipmuck - report

Sgrìobh toki na leanas 12/12/2015 aig 22:51:
> That doesn't mean that work on spell checking and grammar checking 
> should not be done. 
I didn't say that either.
> It does mean that whoever creates the spell checker and grammar 
> checker have a hardcopy (paper) copy of the printed dictionary and 
> grammar checker of the language in question, and understands both what 
> in the book is contentious, and why it is contentious.
Yes but these are skills different to those of a localizer. Not every 
localizer is a grammarian and vice verse and the same applies to the 
writing or even analysis of dictionaries.
> How many people should be on a team is as dependent on cultural 
> factors, as it is on practical factors. 
Agreed
> The vice of a one-person team, is that there is nobody to hand off 
> responsibility for the project off to, if the sole team member is no 
> longer able to work on the project. 
Agreed. Or at least to the extent that if a single localizer fails to 
plan for the future once the project(s) have reached a degree of maturity.
> The vice of multi-member teams, is death by paralysis. The inability 
> to come to mutually acceptable solutions, when questions/problems 
> arise. In the corporate world in Europe and North America, researchers 
> have found that eight people on a team, is the most effective size, 
> for a project to be successful
And my rough and ready analysis has told me you can expect about 1 
active localizer for each half million speakers or so. Like you seems to 
get an almost invariable proportion of lurkers to participants on 
forums, some ratio like that also seems to apply to l10n. Which means 8 
is an almost unachievable number for many languages. All the more reason 
to plan but also an argument for not just turning down folk because they 
haven't got a team.
> a) The primary issue with translating the help file after the rest of 
> the UI, is that it does not get done. (Take a look at the number of 
> localizations of LibO, where the Help file is not translated into the 
> target language.) 
That is one way of looking at it. The other is that of cost vs benefit. 
It would be nice if someone actually did any research but using the 
in-built help in my experience has almost become a joke, like the tools 
Windows includes for automatically fixing issues. In most cases, it does 
not have the answer you're looking for and/or is out of date. Even 
commercial projects with large development teams often product shoddy 
Help, even for key features/issues. Like the Help on using Hunspell in 
Trados.

To be honest I'm surprised LO has not tried to determine if the in-built 
help is actually worth the effort from the end-user POV in contrast to 
online help and/or active user forums etc.

For a small team, it is certainly the smallest bang for you buck in my 
view.
> b) By starting with the Help File, one can incorporate it into the 
> Documentation Work Flow, ensuring the documentation is consistent 
> across the various mediums. Otherwise you end up with situations like 
> the US English, where the written documentation and the help file 
> contradict each other. Even worse, is when both the built-in help 
> file, and written documentation are wrong
Which makes the Help stuff an even worse place to start.
> The advanced/expert users of the software. 
No. They hit Google and find the answer on some forum, wiki or some such 
platform. I would bet the farm on it.
> I realize that Apple pioneered "Prohibit documentation wherever and 
> whenever possible", but all that really results in, is to ensure that 
> the user is unable to use the product as designed
I'm not an Apple disciple, if that's what you're hinting at. If the 
software is well designed, you shouldn't have to resort to Help much.
> It is no more heartbreaking to translate the Help file, as it is to 
> translate the rest of the UI, or the documentation that is in other 
> languages, into the target language.
Fundamentally disagree. The UI on the whole is not that bad and in some 
places, actually a lot of fun (with the Calc functions are probably the 
worst bit of the UI) - on the whole, they're manageable chunks and you 
can use TM to great effect. Help is full of big chunks with eye watering 
tags that confuse not only translators but also TMs. And like 
translating EULAs, all the while you're thinking "who's actually going 
to read this".

It's a bit of a cliché but "more research would be welcome" :)

Michael

--
To unsubscribe e-mail to: l10n+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted