![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
I am interested in setting up a new language localization in Nipmuck, an
native Algonquian tongue from Central New England.
Thanks!
Colin
Sorry for the delay in responding, Im travelling.
<p>I think I disagree with most things that have been said in this discussion so far.
Let me try and go through them one by one...
Somehow the mail client ate most of my email, reposting, sorry...
I am not deterred from thinking that a practical daily use program in the
language would be a great help to those working in it and on it.
I will say that translating literature isn't my gift or talent, but I can
break down technical concepts pretty well.
I am interested in pursuing Firefox as a trial run, and if that doesn't
break me, eventually return to LO and have a go at it.
Thanks to everyone for the input, critique, and advice.
If anyone knows folks on the Mozilla Firefox team I would be deeply
appreciative of an introduction to their l10n effort.
Thank you.
Colin
Hello,
I am not deterred from thinking that a practical daily use program in the
language would be a great help to those working in it and on it.
Oh, of course, this is not what I had in mind. I think the best way to
express yourself is to have the tools in your language. What as said is
that LibreOffice is quite terrible to begin with, and there are
alternatives that maybe really interesting for users and less exhausting
for a translator working alone (I've done it for French for years 
I will say that translating literature isn't my gift or talent, but I can
break down technical concepts pretty well.I am interested in pursuing Firefox as a trial run, and if that doesn't
break me, eventually return to LO and have a go at it.
Great, try to get more people around you, no need for ten persons, but 3
to 4 is already a big team.
Thanks to everyone for the input, critique, and advice.
Don't hesitate to come back to us if you need anything concerning
localization even if it's not LO.
If anyone knows folks on the Mozilla Firefox team I would be deeply
appreciative of an introduction to their l10n effort.
Mihovil gave you the link to their l10n list, if you have difficulty or
lack of answer (but I don't think so) don't hesitate to ping me directly.
Cheers
Sophie
Hi Michael,
Sorry for the delay in responding, Im travelling.
<p>I think I disagree with most things that have been said in this discussion so far.Let me try and go through them one by one...
That is all that arrived on the list. Please send again.
ciao
Christian
1) Orthography
Terrible reason to turn down a project. Most l10n projects LO has invo
lve languages where spelling is a potentially contentious issue.
Nonetheless, every one of the 3,000 languages that have been reduced to
writing has a published dictionary, and grammar. I'll grant that
regardless of which language one is talking about, there will be
contentious issues regarding the accuracy of the book in question. That
doesn't mean that work on spell checking and grammar checking should not
be done. 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.
It also means that when automated tools are used to pare out foreign
words, ensure that only foreign words are omitted. (How many iterations
of the Afrikaans spell checker were needed, before "die" was included in
it? The same thing happens in other languages, but usually aren't as
blatantly obvious omissions to even the most casual user.)
Team Size
Errr no. 1 dedicated localizer is more than enough.
How many people should be on a team is as dependent on cultural factors,
as it is on practical factors.
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.
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.
5) Start with documentation/help
No.It would raise the wrong expectations, if you give the average user
a screen that says Filte, unless highly cynical, they would expect the
rest in the same lingo too.
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.)
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.
As to the Help, who reads the Help?
The advanced/expert users of the software.
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.
its the worst starting point and a soul-destroying task.
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.
jonathon
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
Hi Michael and l10n community
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.
Allow me to plea for the help content.
There is a dimension where documentation get critical, and this is in
the enterprise and in the development. A software that does not carry
proper documentation is subject to several drawbacks.
First, the help desk of the enterprise need to get trained into the
issues of LibreOffice in the same way they need to addres MSOffice
issues. For that they need to know how the software works to assist the
users. Docs and references are crucial, together with proper
professional support.
Second, the help desk is often charged per call. Enterprises where user
cannot find proper doc in their own language is facing a higher TCO,
because users call HD to get what they don't have at hand.
Third, in the way open source is developed and LibreOffice in
particular, there are no specs written in the canonical form a priori
before implementation (as it was in the OpenOffice.org times under
SUN/Oracle) and this is a choice LibreOffice made to offload all hassle
of development and rush into coding improvements long due. The trade-off
is a bunch of nice features very few know how to work and the curious
take much long time to figure it.
Forth, by writing the help pages we have a minimum of a reference guide
to address bugs and regressions. Without a reference, a regression is
allway harder to understand for the developer and the QA guys. Think
about shortcut ABC, that suddenty does not work anymore... how can the
developer be sure the sortcut was inded supposed to do what ABC was
designed originally....
So, users may not like the help content as we have today and don't like
to press F1, but it is our pursuit of quality software to give them the
best we can do in terms of documentation. Admitedly our help system is
not a piece of literature easy to read (nor is MS Office too), but it
must fullfill the mission to establish the landmark of the sofware
behaviour. Yes, "RTFM" comes to my mind actually, but there must be an M
somewhere.
Finaly, other documentation tools like public forums, books, wikis and
even Google are all stars of a documentation constellation but almost
never figure in a help desk SLA. As more litterature we produce on
LibreOffice, the best, because one of the steepest entry barrier we have
to propagate LibreOffice is its lack of culture in the office suite
marketplace, something MS already achieved long ago and is extremely
hard to displace.
Of course, there is room for improvement. The nice part of this is that
it is well suited for the non-code-developer community of LibreOffice.
Give Help a chance.
Kind regards
Olivier,
What you wrote makes sense but seems to talk more about the online help rather than the inbuilt help. I can think of several commercial and OS tools off the top of my head which do not carry inbuilt help these days. Going to Help in Trados for example these days redirects you to the online Help whereas in the old days, there used to be inbuilt Help. Adobe also redirects to F1 user to online Help. MS Office only has vestiges of Help left ("Basic Help" in Word for example about using the Ribbon). Anything else you need to hit the Microsoft website for.
It may be that inbuilt Help was once the norm but I do not think it's going to be the norm for much longer and for obvious reasons (maintaining it seems to be a bit of a nightmare, in contrast to things like wikis).
Don't get me wrong, I'm not suggesting that we need no form of documentation. It's just the inbuilt stuff which I personally feel is becoming more of a liability than a useful tool in LO. Perhaps other/most users *like* inbuilt Help, I don't know, I do not consider myself the arbiter of such things, which is why I said it would be nice if some research was done. But I get the feeling Help is shifting onto the web more and more and if that is the case and if there are good reasons, LO should contemplate this.
Michael
Sgrìobh Olivier Hallot na leanas 13/12/2015 aig 19:05:
Hi All,
+1 on what Michael said about help. I know that traditionally we've had
inbuilt help for a long time, and I know that some feel like it's really
important, but in my opinion, it's more of an emotional factor and
tradition than real need. I especially don't think that maintaining two
sets of help content (one for wiki, one for inbuilt files) independently
makes any sense, and I surely hope we don't do that. If some of us do
that, well, no offence, but in my opinion they're wasting their time. If
"offline help" is so crucial, can't we provide means to download or wiki
as a generated help file, or as a VM instead?
By the way, Oliver, I don't understand why a particular *type* of help
should be mentioned in an SLA at all. Do they charge differently for
questions covered in built-in help, or what? Would anything in the SLA's
have to change drastically if instead of opening the help file F1 would
open a wiki page in a browser?
Rimas
2015-12-13 21:26, Michael Bauer wrote:
Hi All,
+1 on what Michael said about help. I know that traditionally we've had
inbuilt help for a long time, and I know that some feel like it's really
important, but in my opinion, it's more of an emotional factor and
tradition than real need. I especially don't think that maintaining two
sets of help content (one for wiki, one for inbuilt files) independently
makes any sense, and I surely hope we don't do that. If some of us do
that, well, no offence, but in my opinion they're wasting their time. If
"offline help" is so crucial, can't we provide means to download or wiki
as a generated help file, or as a VM instead?
The help on the wiki is exactly the same as the built in help, it's just
an export from what you find on Pootle.
By the way, Oliver, I don't understand why a particular *type* of help
should be mentioned in an SLA at all. Do they charge differently for
questions covered in built-in help, or what? Would anything in the SLA's
have to change drastically if instead of opening the help file F1 would
open a wiki page in a browser?
As already said numerous times here, the aim is to have the ability to
maintain the help in the wiki and still provide on line and off line
help. Not everybody has a connection at low cost, not everybody is
allowed to access the internet in his work, etc... For the moment,
Olivier, Jay, Lera are working on simplifying the use of the help
authoring extension, but it's until the remaining technical problems
with the export to the wiki are solved.
Cheers
Sophie
Sgrìobh Sophie na leanas 16/12/2015 aig 08:56:
The help on the wiki is exactly the same as the built in help, it's just an export from what you find on Pootle.
Seriously? Yikes...
As already said numerous times here, the aim is to have the ability to maintain the help in the wiki and still provide on line and off line help. Not everybody has a connection at low cost, not everybody is allowed to access the internet in his work, etc... For the moment, Olivier, Jay, Lera are working on simplifying the use of the help authoring extension, but it's until the remaining technical problems with the export to the wiki are solved. Cheers Sophie
*to* the wiki? Shouldn't it be the other way round? I have seen in-built Help which was essentially a wiki export but never to date the other way round, at least not knowingly.
Michael
Hi,
2015-12-16 11:05, Michael Bauer wrote:
Sgrìobh Sophie na leanas 16/12/2015 aig 08:56:
The help on the wiki is exactly the same as the built in help, it's
just an export from what you find on Pootle.Seriously? Yikes...
Michael, look on the bright side: at least it's a single set of
information, not two concurrent efforts.
As already said numerous times here, the aim is to have the ability
to maintain the help in the wiki and still provide on line and off
line help. Not everybody has a connection at low cost, not everybody
is allowed to access the internet in his work, etc... For the moment,
Olivier, Jay, Lera are working on simplifying the use of the help
authoring extension, but it's until the remaining technical problems
with the export to the wiki are solved. Cheers Sophie*to* the wiki? Shouldn't it be the other way round? I have seen
in-built Help which was essentially a wiki export but never to date
the other way round, at least not knowingly.
Well, the goal sounds good to me, and if we're moving towards it, that's
fine. I suppose that the content made available for localization is an
export from the English wiki, right? Otherwise, if the content is being
authored externally, and all wikis are just exports of that external
content, I'd say we shouldn't call them wikis at all.
Rimas
what?
Welcome to the wacky world of Help Desks at support centers. Where the
answer is located can have a huge difference on how much the client is
billed. At one establishment I'm familiar with, answers in book number
one were gratis, in book number two cost the client around five bucks
each, and answers from book number the three were charged to the client
for around a grand each. Answers from «F1» help were not gratis, but
answers from official software documentation manuals were gratis. Beyond
that, I don't remember the rule-set used to determine which answer book
to place new solutions in.
jonathon