[libreoffice-l10n] Re: Questions and annotations to guide 2
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] https://wiki.documentfoundation.org/UI_and_Help_files_Content_Guide snip 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 quote 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_valueHeader;Title/bookmark_value, you can just remove it from your translation, as it will have no effect. /quote (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 too ;) Ah, O.K. I did not want to test it, in case it breaks anything ... ;) 3. There is also the following: quote There should not be two similar entries in the help directory because it will break the index display in the help UI. /quote . Should it not be quote 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. /quote or quote 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 ... ;) snip 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 the like? 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 O.K. 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 quote grep -r -i 'word' directory /quote ? You could also use quote grep -ri 'word' directory /quote without any problem (or better say: /I/ can use it with grep 2.14 under Debian Testing AMD64) ... ;) The same applies to quote grep -r -i -n 'word' directory /quote , which you can shorten to quote grep -rin 'word' directory /quote ... ;) 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 another. O.K. 7. Same place: quote 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 to search with double quotes instead of single ones, like in this example: /quote 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: quote you will find more information on the gnu site about the delimiters, the regular expressions and syntax. /quote . 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
Re: [libreoffice-l10n] Re: Questions and annotations to guide 2
Hi :) 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; should avoid try not to please don't it's worth avoiding ... because ... and other such less definite equivalents. Even better is if you can flip it around to say the positive instead. 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 quote 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. /quote 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. General notes 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 sed -h 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 :q 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. man sed 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 Tom :) On Sunday, 13 October 2013, 9:46, Thomas Hackert thack...@nexgo.de 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] https://wiki.documentfoundation.org/UI_and_Help_files_Content_Guide snip 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 quote 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_valueHeader;Title/bookmark_value, you can just remove it from your translation, as it will have no effect. /quote (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 too ;) Ah, O.K. I did not want to test it, in case it breaks anything ... ;) 3. There is also the following: quote There should not
Re: [libreoffice-l10n] Re: Questions and annotations to guide 2
Hi :) 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; quote 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. /quote Regards from Tom :) On , Tom Davies tomdavie...@yahoo.co.uk wrote: Hi :) 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; should avoid try not to please don't it's worth avoiding ... because ... and other such less definite equivalents. Even better is if you can flip it around to say the positive instead. 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 quote 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. /quote 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. General notes 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 sed -h 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 :q 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. man sed 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 Tom :) On Sunday, 13 October 2013, 9:46, Thomas Hackert thack...@nexgo.de 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] https://wiki.documentfoundation.org/UI_and_Help_files_Content_Guide snip 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 quote 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_valueHeader;Title/bookmark_value, you can just remove it from your translation, as it will have no
Re: [libreoffice-l10n] Re: Questions and annotations to guide 2
Hi Tom, Thomas, * Le 13/10/2013 12:54, Tom Davies a écrit : Hi :) 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; should avoid try not to please don't it's worth avoiding ... because ... and other such less definite equivalents. Even better is if you can flip it around to say the positive instead. The reasons I used must not are simple: - makes the reader aware that this is of the most importance: if he breaks the build, his language can't be built or in other cases, the users of his language will lose data, - makes it clear for readers who are not confident with English: 'must' has no ambiguity, this is not the case for 'should' or 'have to'. With 'must', there is no question even if your English is not so good. Kind regards Sophie -- To unsubscribe e-mail to: l10n+unsubscr...@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
