gok r2498 - trunk/po

[leonardof svn gnome org]

Author: leonardof
Date: Sat Jun 28 14:57:35 2008
New Revision: 2498
URL: http://svn.gnome.org/viewvc/gok?rev=2498&view=rev

Log:
2008-06-28  Leonardo Ferreira Fontenelle  <leonardof gnome org>

	* README-TRANSLATORS: Fixed text width to 80 columns.
	* pt_BR.po: Updated and reviewed translation; fixed credits.



Modified:
   trunk/po/ChangeLog
   trunk/po/README-TRANSLATORS
   trunk/po/pt_BR.po

Modified: trunk/po/README-TRANSLATORS
==============================================================================
--- trunk/po/README-TRANSLATORS	(original)
+++ trunk/po/README-TRANSLATORS	Sat Jun 28 14:57:35 2008
@@ -5,8 +5,8 @@
 --------
 
 *.xml.in -> *.xam
-[will add some notes here soon.  These strings tend to be technical and jargon-filled,
-this is normal.  Sorry for the added inconvenience!]
+[will add some notes here soon.  These strings tend to be technical and
+jargon-filled, this is normal.  Sorry for the added inconvenience!]
 
 
 --------
@@ -15,62 +15,65 @@
 
 *.kbd.in -> *.kbd
 
-These files will be marked for translation in the normal way.  
-The merge operation gives us multiple files, one per locale.
-The main reason we prefer multiple files is because the *.kbd files are
-at least potentially human-readable and user-editable.
+These files will be marked for translation in the normal way. The merge 
+operation gives us multiple files, one per locale. The main reason we prefer 
+multiple files is because the *.kbd files are at least potentially 
+human-readable and user-editable.
 
 IMPORTANT: the translations for the short strings in the kbd.in files, should
 be kept short.  Ideally they should not exceed the length of the original.  If 
-they are too long there is a risk that part of the translation will not be readable.
+they are too long there is a risk that part of the translation will not be 
+readable.
 
 --------
-Some *.kbd files such as "Keyboard.kbd" are not included in POTFILES.in.  
-This is intentional, since some KBD files are not suited for string-based 
-translation but are locale-specific.  Instead of extracting and translating 
-the strings in these files, locale-appropriate versions of "Keyboard.kbd" should 
-be created for each locale and placed in the appropriate subdirectory in gok/keyboards/.  
-If a subdirectory for your locale doesn't exist yet, please add it to gok/keyboards.
-
-Note that the *.kbd files are mostly collections of "Gok:key" elements, whose relative position
-in a tabular onscreen arrangement is determined by "left", "right", "top", and "bottom" elements.
-Most keys are one cell wide and one cell tall, therefore right==left+1 and bottom==top+1.
-If you run GOK in C locale with these keyboards you can see what they do, for instance
-"gok --keyboard Keyboard"
+Some *.kbd files such as "Keyboard.kbd" are not included in POTFILES.in. This is
+intentional, since some KBD files are not suited for string-based translation 
+but are locale-specific.  Instead of extracting and translating the strings in 
+these files, locale-appropriate versions of "Keyboard.kbd" should be created 
+for each locale and placed in the appropriate subdirectory in gok/keyboards/. If
+a subdirectory for your locale doesn't exist yet, please add it to 
+gok/keyboards.
+
+Note that the *.kbd files are mostly collections of "Gok:key" elements, whose 
+relative position in a tabular onscreen arrangement is determined by "left", 
+"right", "top", and "bottom" elements. Most keys are one cell wide and one cell tall, therefore right==left+1 and bottom==top+1. If you run GOK in C locale with
+these keyboards you can see what they do, for instance "gok --keyboard Keyboard"
 
 * About Keyboard.kbd (known in english as "qwerty.kbd")
 
-This keyboard's layout is intended to match a representative sample of a physical
-keyboard for a given locale.  Generally only one of each modifier key is included, and
-things like the numberpad are omitted.  Some keys may span more than one cell in the
-vertical or horizontal direction.
-
-In addition to these files, a few other keyboard-related strings need to be localized.
-(Note that as of July 1 2003, GOK version 0.7.9, these strings are not used by GOK but 
-we *do* plan to use them in the near future to implement fully-internationalized alphabetical 
-and frequency-table keyboard layouts, as our current internal implementation is not very
-i18n-friendly. -- Bill).
-The strings which appear in english/C as "abcdefghij....", and "ABCDEF...",
-"ÃâÂÃeÄÅÄ..." represent the alphabetic sequence of characters in the locale for various shift levels.
-If your locale includes more than three shift levels, the empty string(s) after "ABCD..."
-should be translated to the corresponding character sequences for subsequent shift levels.
-"spacebar tab" should be translated to the name of the character which the spacebar
-produces; if the locale does not include whitespace characters, this string
-should be translated to the empty string.  Similar rules apply to the string "Tab".
-"Shift AltGr" should be translated to a list of modifier names corresponding to
-the strings "abcd...", "ABCD...", etc.  If your locale includes more than three shift levels,
-the names of the additional shift levels should be included in the translation of "Shift AltGr ..."
-
-The english text strings corresponding to "etaoin...", "ETAOIN...", should be translated
-as above, except that the characters should occur in frequency order.  The frequency order is
-not critical, approximate order will do if you don't have access to a character frequency 
-table for your target locale.  (These strings are used by GOK to determine placement of
-keys so that most-frequently-used characters are easiest/fastest to insert, for 
-scanning access methods.)
-
-Note that at the moment GOK can scan right-to-left in RTL locales.  (NOTE: Our original 
-intention was that in RTL locales, '0' will mean the right-hand side, thus the back key should 
-be at "left=1, right=0", but this is NOT the case)
+This keyboard's layout is intended to match a representative sample of a 
+physical keyboard for a given locale.  Generally only one of each modifier key 
+is included, and things like the numberpad are omitted.  Some keys may span more
+than one cell in the vertical or horizontal direction.
+
+In addition to these files, a few other keyboard-related strings need to be 
+localized. (Note that as of July 1 2003, GOK version 0.7.9, these strings are 
+not used by GOK but we *do* plan to use them in the near future to implement 
+fully-internationalized alphabetical and frequency-table keyboard layouts, as 
+our current internal implementation is not very i18n-friendly. -- Bill). The 
+strings which appear in english/C as "abcdefghij....", and "ABCDEF...", 
+"ÃâÂÃeÄÅÄ..." represent the alphabetic sequence of characters in the locale for
+various shift levels. If your locale includes more than three shift levels, the
+empty string(s) after "ABCD..." should be translated to the corresponding 
+character sequences for subsequent shift levels. "spacebar tab" should be 
+translated to the name of the character which the spacebar produces; if the 
+locale does not include whitespace characters, this string should be translated
+to the empty string.  Similar rules apply to the string "Tab". "Shift AltGr"
+should be translated to a list of modifier names corresponding to the strings
+"abcd...", "ABCD...", etc.  If your locale includes more than three shift 
+levels, the names of the additional shift levels should be included in the 
+translation of "Shift AltGr ..."
+
+The english text strings corresponding to "etaoin...", "ETAOIN...", should be 
+translated as above, except that the characters should occur in frequency order.
+The frequency order is not critical, approximate order will do if you don't have
+access to a character frequency table for your target locale.  (These strings 
+are used by GOK to determine placement of keys so that most-frequently-used 
+characters are easiest/fastest to insert, for scanning access methods.)
+
+Note that at the moment GOK can scan right-to-left in RTL locales.  (NOTE: Our 
+original intention was that in RTL locales, '0' will mean the right-hand side, 
+thus the back key should be at "left=1, right=0", but this is NOT the case)
 
 ========