Actually i made a typo in 3. "There should not BE more..." ("be" in lower-case though. I just
wanted to emphasis my error).
It still looks clunky to me. Perhaps rewrite it to something like;
Entries that look like they are duplicates will probably break the indexing display in the UI even
if those entries come from different parts of the document.
On , Tom Davies <firstname.lastname@example.org> wrote:
I tend to dislike "must not" too. It's soo authoritarian that it makes me want to go against it or
to find out why not by experimentation. I prefer things like;
try not to
it's worth avoiding ... because ...
and other such less definite equivalents. Even better is if you can flip it around to say the
3. Looks clunky. I do prefer the 3rd way of writing it but can now see the problem that Sophie
was trying to avoid. Perhaps
There should not more than one entry with the same contents in the help directory because it will
break the index display in the help UI.
Perhaps instead of "contents" it might be better to use another word such as; text, value, errr i
can't think of others but maybe Anne-ology might know a much better choice.
In 5 & 6 i agree with Sophie. It is less elegant but is less likely to create confusion. When a
number of tags get combined (as in "-rin") it almost looks like a word that might need to be
translated whereas separately they are clearly tags/options. People probably wouldn't try to
translate "-r -i -n".
There are tags that are entire words and those might need translating, for example with the rsync
command there is "--partial" and "--progress" but
a) Those have a double "-" sign
b) Only translate if the under-laying OS is in a non-English language and only if the particular
command has been translated
There are too many ifs there so it's probably worth avoiding those sorts of tags
7 "Escape character" might be written as "escaping character" without changing the meaning. The
grammar of the sentence might require an "ing", or else the term would need to be defined. Devs
and coders might have a more precise meaning for the term but i think the usage is sufficiently
close and is readily understood by normal users without explanation.
It is good to learn about built-in help available on the command-line and easy to look-up without
going off and opening a web-browser but i agree with Sophie that it is all really a subject for
other books and faqs and there are plenty of them already! People still don't know all about all
this and there is no reason they should. I hadn't known of "info" until this post so thanks for
that! :) I generally use "--help" or "-h" to get a quick little "cheat sheet" or "quick reference
card" about a command before running it. For example
The "man" pages give a LOT more detail but it's awkward to keep them open while typing on the
command-line itself (unless you open it in a new windows or tab). Also it took me ages to realise
that it was a "vi" editor and that i could escape by using
before that i was a bit stuck because even "Ctrl c" wouldn't get me back to the command-line and
i'd have to close the "terminal console" / "command-prompt window". Now i know about ":q" it's
easier for me.
Anyway, nicely done! Especially with 3. That was a good catch :) The other questions were good
to find out about, discuss and agree a general policy about so that was all good too. :D
Congrats and regards from
On Sunday, 13 October 2013, 9:46, Thomas Hackert <email@example.com> wrote:
Hello Sophie, *,
On Sonntag, 13. Oktober 2013 09:42 Sophie wrote:
Le 12/10/2013 19:59, Thomas Hackert a écrit :
On Freitag, 11. Oktober 2013 09:17 Sophie wrote:
[two new guides to Pootle]
1. You have really often used "must not". I have changed some of
them to "have not to", "need not" or tried to circumvent them
otherwise ... ;) But there are still a lot of them in the text,
so it would be nice, if someone has another look at it ... ;)
I am not sure (my last English lesson is too far in the past,
sorry), but was it not mostly used in official texts, legal
instruments and the like?
I used 'must not' because it's a 'must not' :)
O.K. Still ... Maybe we should either replace a couple of them to
"to have not to", "need not to" or the like, as it sounds a little
bit ... annoying IMHO ... ;)
But I still have this ticking "you should not use 'must not' in
English texts" in the back of my head ... ;)
2. Below "3.3 <bookmark_value></bookmark_value>" you wrote
Sometimes it happens that the word in the sources has a different
meaning in English but not in your language, like header and
title. If you find such entry like
<bookmark_value>Header;Title</bookmark_value>, you can just
remove it from your translation, as it will have no effect.
(first point below the grey box). Are you sure, that you really
can remove it? I seem to remember, that either Pootle will spit
out an error message or there will be a problem during compiling
LO (but I may be wrong here ... ;) ).
Yes, I'm sure, I've already done it (and already broke the index
Ah, O.K. I did not want to test it, in case it breaks anything ...
3. There is also
There should not be two similar entries in the help directory
because it will break the index display in the help UI.
. Should it not be
There should not be the same entry more than one time in the help
directory because it will break the index display in the help UI.
There should not more than one entry with the same name in the
help directory because it will break the index display in the
help UI. </quote>
(or something like that ... ;) ) instead?
For me it means the same, but if you prefer one over another,
please change it. Your last proposition however could be difficult
to understand, because 'name' is less precise.
O.K., but similar !=
same ... ;)
5. Same paragraph: Just out of interest: Why do you link to
Translate Toolkit's online documentation? Would it not be more
helpful to mention "man poterminoloy" or "info poterminology" and
I did so because most of the translators are not technical at all
and will prefer to read the help on a web page than on a terminal
6. Thank you for "4.2 Using grep to find strings" :) Some really
interesting information in it, nice :) But why do you write every
option separatly? Like
grep -r -i 'word' directory
? You could also use
grep -ri 'word' directory
without any problem (or better say: /I/ can use it with grep 2.14
Testing AMD64) ... ;) The same applies to
grep -r -i -n 'word' directory
, which you can shorten to
grep -rin 'word' directory
same as above, I prefer they really understand what they do, so
step by step with one option separated from the others, when you
learn, it is easier to execute and remember. I could have given
only one command line with all the parameters explained below, but
when it's your first try, it is safe to do one thing after
7. Same place:
If you have an escaping character in your search, like an
apostrophe (e.g. child's book in English or l'objet in French),
the simplest way to overcome that is to enclose the word
search with double quotes instead of single ones, like in this
What do you mean with "escaping character" here? Did you not mean
"characters to escape"?
I mean an apostrophe, like I mentioned it, it is an escaping
character that will be interpreted when you don't want it.
Maybe I do understand you wrong here, but an apostrophe is an
punctuation mark (or diacritical mark, see
http://en.wikipedia.org/wiki/Apostrophe), whereas an escape
character would be a character, which is used in a shell, a program
or the like (there are also metacharacters, see
http://en.wikipedia.org/wiki/Metacharacter ... ;) ), as it it
explained in http://en.wikipedia.org/wiki/Escape_character ... ;) I
have not heard "escaping character" before, but that does not mean
anything ... ;)
8. The last sentence from "4.3 Using sed to modify your files":
you will find more information on the gnu site about the
delimiters, the regular expressions and syntax.
. Why do you link to the online version of the manpage from sed,
when it is installed on your system ;? And you could use "info
sed" as well to get additional information ... ;)
same as above. My position here is to help people who have never
touched a terminal and they will feel more at ease reading out of
O.K. Though I was really pleased, when I found out, that there is
such a nice "feature" like "man $program" or "info $program", and I
to open a browser every time, when I had a problem with the
usage of a program ... ;)
9. Some of the text of the grey boxes with the examples are too
long, when I view them with FF 27.0a1 (2013-10-12) under Debian
Testing AMD64 and using a display resolution of 1024x768 (like
the box with
#1 Verify Impress is running \n
#2 For Bluetooth user, enable "Preferences"-"LibreOffice
Impress"-"General"-"Enable remote control"\n
#3 For WiFi user, tick
, where the last part of the second line (l"\n") is outside of
the box ... :( Is there a possibility to get the texts inside the
grey box (either resizing the box or splitting the lines or ...)?
the box get the size of the
sentence, so I'll split the sentence
in more lines.
That would be nice, thank you :)
That was all, I have found so far ... ;) Have a nice evening
Thanks a lot for your proof reading and suggestions :)
You are welcome :)
Have a nice day
"You have heard me speak of Professor Moriarty?"
"The famous scientific criminal, as famous among crooks as --"
"My blushes, Watson," Holmes murmured, in a deprecating voice.
"I was about to say 'as he is unknown to the public.'"
-- A. Conan Doyle, "The Valley of Fear"
To unsubscribe e-mail to: firstname.lastname@example.org
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
Re: [libreoffice-l10n] Documentation for l10n · Leo Moons
- Re: [libreoffice-l10n] Re: Re: Re: Documentation for l10n (continued)
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy