applied typos and spelling error fixes patch from Olly Betts
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@15779 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
@@ -444,7 +444,7 @@ While editing a PO file, PO mode allows for the easy browsing of
|
||||
auxiliary and compendium PO files, as well as for following references into
|
||||
the set of C program sources from which PO files have been derived.
|
||||
It has a few special features, among which are the interactive marking
|
||||
of program strings as translatable, and the validatation of PO files
|
||||
of program strings as translatable, and the validation of PO files
|
||||
with easy repositioning to PO file lines showing errors.
|
||||
|
||||
</P>
|
||||
|
@@ -153,7 +153,7 @@ translator teams get interested in your package, and submit PO files.
|
||||
<P>
|
||||
It is worth adding here a few words about how the maintainer should
|
||||
ideally behave with PO files submissions. As a maintainer, your role is
|
||||
to authentify the origin of the submission as being the representative
|
||||
to authenticate the origin of the submission as being the representative
|
||||
of the appropriate translating teams of the Translation Project (forward
|
||||
the submission to <TT>`translation@iro.umontreal.ca'</TT> in case of doubt),
|
||||
to ensure that the PO file format is not severely broken and does not
|
||||
|
@@ -17,7 +17,7 @@
|
||||
|
||||
<P>
|
||||
The ISO 639 standard defines two character codes for many countries.
|
||||
All abreviations for countries or languages used in the Translation
|
||||
All abbreviations for countries or languages used in the Translation
|
||||
Project should come from this standard.
|
||||
|
||||
</P>
|
||||
|
@@ -149,7 +149,7 @@ the full control she needs.
|
||||
The comment lines beginning with <KBD>#,</KBD> are special because they are
|
||||
not completely ignored by the programs as comments generally are. The
|
||||
comma separated list of <VAR>flag</VAR>s is used by the <CODE>msgfmt</CODE>
|
||||
program to give the user some better disgnostic messages. Currently
|
||||
program to give the user some better diagnostic messages. Currently
|
||||
there are two forms of flags defined:
|
||||
|
||||
</P>
|
||||
@@ -171,7 +171,7 @@ search only. See section <A HREF="gettext_5.html#SEC26">Fuzzy Entries</A>.
|
||||
<DT><KBD>no-c-format</KBD>
|
||||
<DD>
|
||||
These flags should not be added by a human. Instead only the
|
||||
<CODE>xgettext</CODE> program adds them. In an automatized PO file processing
|
||||
<CODE>xgettext</CODE> program adds them. In an automated PO file processing
|
||||
system as proposed here the user changes would be thrown away again as
|
||||
soon as the <CODE>xgettext</CODE> program generates a new template file.
|
||||
|
||||
@@ -199,7 +199,7 @@ not having GNU Emacs handy should carefully continue reading on.
|
||||
<P>
|
||||
Each of <VAR>untranslated-string</VAR> and <VAR>translated-string</VAR> respects
|
||||
the C syntax for a character string, including the surrounding quotes
|
||||
and imbedded backslashed escape sequences. When the time comes
|
||||
and embedded backslashed escape sequences. When the time comes
|
||||
to write multi-line strings, one should not use escaped newlines.
|
||||
Instead, a closing quote should follow the last character on the
|
||||
line to be continued, and an opening quote should resume the string
|
||||
@@ -540,7 +540,7 @@ merely use <KBD>x</KBD> for making the switch.
|
||||
There are many different ways for encoding a particular string into a
|
||||
PO file entry, because there are so many different ways to split and
|
||||
quote multi-line strings, and even, to represent special characters
|
||||
by backslahsed escaped sequences. Some features of PO mode rely on
|
||||
by backslashed escaped sequences. Some features of PO mode rely on
|
||||
the ability for PO mode to scan an already existing PO file for a
|
||||
particular string encoded into the <CODE>msgid</CODE> field of some entry.
|
||||
Even if PO mode has internally all the built-in machinery for
|
||||
|
@@ -94,7 +94,7 @@ numbers in the <CODE>"C"</CODE> locale format. In some situation, it might
|
||||
also be a problem with the notation itself which makes it impossible to
|
||||
recognize whether the number is in the <CODE>"C"</CODE> locale or the local
|
||||
format. This can happen if thousands separator characters are used.
|
||||
Some locales define this character accordfing to the national
|
||||
Some locales define this character according to the national
|
||||
conventions to <CODE>'.'</CODE> which is the same character used in the
|
||||
<CODE>"C"</CODE> locale to denote the decimal point.
|
||||
|
||||
@@ -524,7 +524,7 @@ Consider the following case:
|
||||
<P>
|
||||
While it is no problem to mark the string <CODE>"a default message"</CODE> it
|
||||
is not possible to mark the string initializers for <CODE>messages</CODE>.
|
||||
What is to be done? We have to fulfill two tasks. First we have to mark the
|
||||
What is to be done? We have to fulfil two tasks. First we have to mark the
|
||||
strings so that the <CODE>xgettext</CODE> program (see section <A HREF="gettext_4.html#SEC20">Invoking the <CODE>xgettext</CODE> Program</A>)
|
||||
can find them, and second we have to translate the string at runtime
|
||||
before printing them.
|
||||
|
@@ -106,7 +106,7 @@ Join messages with existing file.
|
||||
<DD>
|
||||
<DT><SAMP>`--keyword[=<VAR>word</VAR>]'</SAMP>
|
||||
<DD>
|
||||
Additonal keyword to be looked for (without <VAR>word</VAR> means not to
|
||||
Additional keyword to be looked for (without <VAR>word</VAR> means not to
|
||||
use default keywords).
|
||||
|
||||
The default keywords, which are always looked for if not explicitly
|
||||
@@ -194,7 +194,7 @@ adjacent strings, and escaped end of lines for continued strings.
|
||||
<H2><A NAME="SEC21" HREF="gettext_toc.html#TOC21">C Sources Context</A></H2>
|
||||
|
||||
<P>
|
||||
PO mode is particularily powerful when used with PO files
|
||||
PO mode is particularly powerful when used with PO files
|
||||
created through GNU <CODE>gettext</CODE> utilities, as those utilities
|
||||
insert special comments in the PO files they generate.
|
||||
Some of these special comments relate the PO file entry to
|
||||
@@ -205,7 +205,7 @@ exactly where the untranslated string appears in the program sources.
|
||||
When the translator gets to an untranslated entry, she is fairly
|
||||
often faced with an original string which is not as informative as
|
||||
it normally should be, being succinct, cryptic, or otherwise ambiguous.
|
||||
Before chosing how to translate the string, she needs to understand
|
||||
Before choosing how to translate the string, she needs to understand
|
||||
better what the string really means and how tight the translation has
|
||||
to be. Most of times, when problems arise, the only way left to make
|
||||
her judgment is looking at the true program sources from where this
|
||||
@@ -222,7 +222,7 @@ translator should not be shy at taking a look, once in a while.
|
||||
It is most probable that she will still be able to find some of the
|
||||
hints she needs. She will learn quickly to not feel uncomfortable
|
||||
in program code, paying more attention to programmer's comments,
|
||||
variable and function names (if he dared chosing them well), and
|
||||
variable and function names (if he dared choosing them well), and
|
||||
overall organization, than to programmation itself.
|
||||
|
||||
</P>
|
||||
|
@@ -70,7 +70,7 @@ See section <A HREF="gettext_5.html#SEC26">Fuzzy Entries</A>.
|
||||
|
||||
<P>
|
||||
Each PO file entry may have a set of <STRONG>attributes</STRONG>, which are
|
||||
qualities given an name and explicitely associated with the entry
|
||||
qualities given an name and explicitly associated with the entry
|
||||
translation, using a special system comment. One of these attributes
|
||||
has the name <CODE>fuzzy</CODE>, and entries having this attribute are said
|
||||
to have a fuzzy translation. They are called fuzzy entries, for short.
|
||||
|
@@ -70,7 +70,7 @@ translation errors. The <CODE>msgid</CODE> and <CODE>msgstr</CODE> strings are
|
||||
studied and compared. It is considered abnormal that one string
|
||||
starts or ends with a newline while the other does not.
|
||||
|
||||
Also, if the string represents a format sring used in a
|
||||
Also, if the string represents a format string used in a
|
||||
<CODE>printf</CODE>-like function both strings should have the same number of
|
||||
<SAMP>`%'</SAMP> format specifiers, with matching types. If the flag
|
||||
<CODE>c-format</CODE> or <CODE>possible-c-format</CODE> appears in the special
|
||||
|
@@ -167,7 +167,7 @@ On the other end, people might enjoy their own language a lot, and be
|
||||
very motivated at providing to themselves the pleasure of having their
|
||||
beloved free software speaking their mother tongue. They do themselves
|
||||
a personal favor, and do not pay that much attention to the number of
|
||||
people beneficiating of their work.
|
||||
people benefiting of their work.
|
||||
|
||||
<LI>Misinterpretation
|
||||
|
||||
|
Reference in New Issue
Block a user