Localization/Concepts/PO Odyssey - Revision history

AnneW at 16:00, 15 July 2012

2012-07-15T16:00:16Z

Neverendingo: Text replace - "`" to ""`


2011-06-29T21:09:16Z
Text replace - "<code po>" to "<syntaxhighlight lang="text">"
Show changes



Neverendingo: Text replace - "" to ""

2011-06-29T21:00:03Z
Text replace - "<code cpp>" to "<syntaxhighlight lang="cpp">"

				
				
				
				
			
			← Older revision
			Revision as of 21:00, 29 June 2011
			
Line 105:
Line 105:
  is of that kind. Then, by following the source reference, you see this statement in the file <tt>addcatdialog.cpp</tt>, line 45:   is of that kind. Then, by following the source reference, you see this statement in the file <tt>addcatdialog.cpp</tt>, line 45:
    
− <code cpp> + <syntaxhighlight lang="cpp">
  setCaption( i18n( "Import Catalog" ) );   setCaption( i18n( "Import Catalog" ) );
  </syntaxhighlight>   </syntaxhighlight>



Neverendingo: Text replace - "" to ""
2011-06-29T20:57:20Z
Text replace - "</code>" to "</syntaxhighlight>"
Show changes


Neverendingo: Text replace - "" to ""

2011-06-29T20:42:41Z
Text replace - "<code>" to "<syntaxhighlight lang="text">"

				
				
				
				
			
			← Older revision
			Revision as of 20:42, 29 June 2011
			
Line 651:
Line 651:
  But, how should the application know which form corresponds to which numbers? The specification for this is written within the PO file itself, in the ''header'' (more on PO headers [[#PO Header|below]]); it consists of the number of plural forms which every plural message in the given PO file shall have, and a computable logical expression, which for any given number, computes the index of the plural form to be used. This expression is quite cryptic-looking, but you do not have to really understand how it works. Since it is constant for a given language, you can just copy it from any other previously translated PO file in your language, and by looking at plural messages in that other file, you will clearly see which form (by index of <tt>msgstr</tt>) is used in which situation. Bearing this in mind, just to complete the examples, here is the plural specification for Spanish:   But, how should the application know which form corresponds to which numbers? The specification for this is written within the PO file itself, in the ''header'' (more on PO headers [[#PO Header|below]]); it consists of the number of plural forms which every plural message in the given PO file shall have, and a computable logical expression, which for any given number, computes the index of the plural form to be used. This expression is quite cryptic-looking, but you do not have to really understand how it works. Since it is constant for a given language, you can just copy it from any other previously translated PO file in your language, and by looking at plural messages in that other file, you will clearly see which form (by index of <tt>msgstr</tt>) is used in which situation. Bearing this in mind, just to complete the examples, here is the plural specification for Spanish:
    
− <code> + <syntaxhighlight lang="text">
  nplurals=2; plural=n != 1;   nplurals=2; plural=n != 1;
  </code>   </code>
Line 657:
Line 657:
  and for the more complicated Polish plural:   and for the more complicated Polish plural:
    
− <code> + <syntaxhighlight lang="text">
  nplurals=3; plural=(n==1 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);   nplurals=3; plural=(n==1 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);
  </code>   </code>



Ilic: Fixed extracted comment.
2008-09-30T11:28:25Z
Fixed extracted comment.

				
				
				
				
			
			← Older revision
			Revision as of 11:28, 30 September 2008
			
Line 245:
Line 245:
  msgstr ""   msgstr ""
  ⁠   ⁠
− # i18n: South + #. i18n: South
  #: skycomponents/horizoncomponent.cpp:429   #: skycomponents/horizoncomponent.cpp:429
  msgid "S"   msgid "S"



Ilic: Section on obsolete messages.
2008-09-28T13:53:09Z
Section on obsolete messages.

				
				
				
				
			
			← Older revision
			Revision as of 13:53, 28 September 2008
			
Line 715:
Line 715:
  This is done in the following way. On the one side, there is your last translated version of the PO file. On the other side, there is the latest pristine PO, with non-translated messages corresponding to the current state of the source. Pristine PO files are actually called ''templates'', and have the <tt>.pot</tt> extension, unlike the <tt>.po</tt> extension of translated POs. The translated PO file and the template are then ''merged'' in a special way, producing a new, partially translated PO for you to work on. The technicalities of merging are not so important at first, as in any established translation project you can just fetch the latest merged PO files; more is important is what you can expect to see in a merged PO file.   This is done in the following way. On the one side, there is your last translated version of the PO file. On the other side, there is the latest pristine PO, with non-translated messages corresponding to the current state of the source. Pristine PO files are actually called ''templates'', and have the <tt>.pot</tt> extension, unlike the <tt>.po</tt> extension of translated POs. The translated PO file and the template are then ''merged'' in a special way, producing a new, partially translated PO for you to work on. The technicalities of merging are not so important at first, as in any established translation project you can just fetch the latest merged PO files; more is important is what you can expect to see in a merged PO file.
    
− In general, merged PO files contain three categories of messages. First are those messages which were present in the PO file when you last worked on it, in the sense of having unchanged <tt>msgctxt</tt> and <tt>msgid</tt> fields since then. As expected, their translations (<tt>msgstr</tt> fields) are as you left them, so there is nothing new for you to do about these messages. The second category are entirely new messages, added in the source in the meantime, which you should now translate. New messages won't be added in an arbitrary way, for example simply appended to the end of the PO file. Instead they will be interspersed with translated messages, following the order of appearance of messages in the current source. This allows you to infer contexts by considering the preceding and following messages, same as you did when you were translating the PO from scratch. For example: + In general, merged PO files contain four categories of messages. First are those messages which were present in the PO file when you last worked on it, in the sense of having unchanged <tt>msgctxt</tt> and <tt>msgid</tt> fields since then. As expected, their translations (<tt>msgstr</tt> fields) are as you left them, so there is nothing new for you to do about these messages. The second category are entirely new messages, added in the source in the meantime, which you should now translate. New messages won't be added in an arbitrary way, for example simply appended to the end of the PO file. Instead they will be interspersed with translated messages, following the order of appearance of messages in the current source. This allows you to infer contexts by considering the preceding and following messages, same as you did when you were translating the PO from scratch. For example:
    
  <code po>   <code po>
Line 801:
Line 801:
    
  That a fuzzy message is treated as untranslated is important to keep in mind. Fresh translators will sometimes manually add the <tt>fuzzy</tt> flag to a message to mark they are not entirely sure that the translation is proper, not knowing that this will totally exclude the translation from being used. Thus, you should manually add the <tt>fuzzy</tt> flag ''only'' when you are so unsure of the meaning of the message, that you explicitly want to prevent the translation from being used. This is fairly rarely needed. Instead, when you just want to mark the message so that you or someone else can check it later, you should write your doubts in a [[#Translator Comments|translator comment]].   That a fuzzy message is treated as untranslated is important to keep in mind. Fresh translators will sometimes manually add the <tt>fuzzy</tt> flag to a message to mark they are not entirely sure that the translation is proper, not knowing that this will totally exclude the translation from being used. Thus, you should manually add the <tt>fuzzy</tt> flag ''only'' when you are so unsure of the meaning of the message, that you explicitly want to prevent the translation from being used. This is fairly rarely needed. Instead, when you just want to mark the message so that you or someone else can check it later, you should write your doubts in a [[#Translator Comments|translator comment]].
  + 
  + === Obsolete Messages ===
  + 
  + The last, fourth category are ''obsolete'' messages. These are the messages which are neither present in the source content any more, nor were judged by the merging algorithm as appropriate to base a fuzzy message on. All obsolete messages are grouped at the end of the merged PO file, and fully commented out by the <tt>#~</tt> comment:
  + 
  + <code po>
  + #~ msgid "Set the telescope longitude and latitude."
  + #~ msgstr "Postavi geo. dužinu i širinu teleskopa."
  + </code>
  + 
  + Obsolete messages have no extracted comments or source references, as they are no longer present in the source. Translator comments and flags will be retained, as they don't depend on the presence in the source.
  + 
  + It could be said that obsolete messages are in fact no messages at all, given that they don't exist from the point of consumers of the PO file, and there is nothing for translators to do with them. PO tools in general will ignore them, except to sometimes preserve them if modifying the PO file. Dedicated PO editors will invariably not show obsolete messages to the user, and may provide an option to automatically remove them from the file on saving.
  + 
  + What is then the purpose of obsolete messages? It frequently happens that a section of the source content, e.g. the code around a certain feature of an application, is ''temporarily'' removed. Authors sometimes want to improve a section separately, outside of the main content which is being translated, and sometimes a section is even briefly omitted by mistake when there are moves and renames in the source. When this happens, the affected messages will become obsolete in the merged PO; but, when the missing section is put back into the source, the merging algorithm will take obsolete messages into account, and promote them to real messages (either translated or fuzzy) where possible. Thus, some needless translation work may be saved.
  + 
  + What you should do with obsolete messages depends on the tools with which you work on PO files. For example, if you and other translators working on the given PO all use dedicated PO editors with internal storage of all previously encountered translations, the ''translation memory'', there is less need for keeping obsolete messages around, as the editor will be able to fill new messages from the memory; but there are some difficulties, as the need for translators to share the same memory. In practice, many translators opt to keep obsolete messages around for some time, and periodically (e.g. months apart) remove them from PO files. By this they achieve that accidental removals of source content, which are quickly corrected, rarely bother them, while avoiding accretion of far too much obsolete material.
    
  === Starting a New PO file ===   === Starting a New PO file ===



Ilic: Add message layout in Poedit. Reduce size of thumbnails.
2008-09-12T22:50:13Z
Add message layout in Poedit. Reduce size of thumbnails.

				
				
				
				
			
			← Older revision
			Revision as of 22:50, 12 September 2008
			
Line 922:
Line 922:
  === Kate ===   === Kate ===
    
− [[Image:Kate_pomsg_01_ann.png|right|200px|PO message in Kate 3.1.0]] + [[Image:Kate_pomsg_01_ann.png|right|150px|PO message in Kate 3.1.0]]
    
  KWrite and Kate are KDE's standard low-high team of text editors, which share the same text editing component. The syntax highlighting for the PO format shown on the screenshot was introduced in version 3.1.0 of Kate (released with KDE 4.1.0), while earlier versions had simpler highlighting. However, the new PO highlighting definition works equally well with versions from 2.4.0 onwards, so you can fetch it if you are using an older Kate.   KWrite and Kate are KDE's standard low-high team of text editors, which share the same text editing component. The syntax highlighting for the PO format shown on the screenshot was introduced in version 3.1.0 of Kate (released with KDE 4.1.0), while earlier versions had simpler highlighting. However, the new PO highlighting definition works equally well with versions from 2.4.0 onwards, so you can fetch it if you are using an older Kate.
Line 930:
Line 930:
  === Lokalize ===   === Lokalize ===
    
− [[Image:Lokalize_pomsg_02_ann.png|right|200px|PO message in Lokalize 0.2]] + [[Image:Lokalize_pomsg_02_ann.png|right|150px|PO message in Lokalize 0.2]]
    
  [[Localization/Tools/Lokalize|Lokalize]] is the new dedicated PO editor (a general translation application in fact) for KDE 4, replacing KBabel in that role. The layout on the screenshot is only the default, you can rearrange display and editing widgets in any way you like.   [[Localization/Tools/Lokalize|Lokalize]] is the new dedicated PO editor (a general translation application in fact) for KDE 4, replacing KBabel in that role. The layout on the screenshot is only the default, you can rearrange display and editing widgets in any way you like.
Line 938:
Line 938:
  === Gtranslator ===   === Gtranslator ===
    
− [[Image:Gtranslator_pomsg_01_ann.png|right|200px|PO message in Gtranslator 1.1.8]] + [[Image:Gtranslator_pomsg_01_ann.png|right|150px|PO message in Gtranslator 1.1.8]]
    
  [http://gtranslator.sourceforge.net/ Gtranslator] is a dedicated PO editor for Gnome. In the versions prior to the current 1.1.8 it was not able to open a PO file with <tt>msgctxt</tt> fields (since these are the newest addition to PO format), and in the current stable version it will open such files, but it will not display the content of <tt>msgctxt</tt> to the user (hence the red number 3 lower right). This is about to be implemented in the upcoming releases, as <tt>msgctxt</tt> is starting to get used in Gnome POs themselves.   [http://gtranslator.sourceforge.net/ Gtranslator] is a dedicated PO editor for Gnome. In the versions prior to the current 1.1.8 it was not able to open a PO file with <tt>msgctxt</tt> fields (since these are the newest addition to PO format), and in the current stable version it will open such files, but it will not display the content of <tt>msgctxt</tt> to the user (hence the red number 3 lower right). This is about to be implemented in the upcoming releases, as <tt>msgctxt</tt> is starting to get used in Gnome POs themselves.
  + 
  + === Poedit ===
  + 
  + [[Image:Poedit_pomsg_01_ann.png|right|150px|PO message in Poedit 1.4.1]]
  + 
  + [http://www.poedit.net/ Poedit] is a multiplatform dedicated PO editor. It suports translation memories and plural forms. It can open PO files containing <tt>msgctxt</tt> fields, but does not display them to the user as of version 1.4.1. Source references can be seen by right-clicking on the message in the list.
  + 
  + Poedit's primary visual feature is its compact layout. It can also work in full-screen mode.
    
  == Contacting Authors ==   == Contacting Authors ==



Ilic: Remove parenthesis around plural= expressions where so in KDE.
2008-09-08T10:59:44Z
Remove parenthesis around plural= expressions where so in KDE.

				
				
				
				
			
			← Older revision
			Revision as of 10:59, 8 September 2008
			
Line 652:
Line 652:
    
  <code>   <code>
− nplurals=2; plural=(n != 1); + nplurals=2; plural=n != 1;
  </code>   </code>
    
Line 853:
Line 853:
  "Content-Type: text/plain; charset=UTF-8\n"   "Content-Type: text/plain; charset=UTF-8\n"
  "Content-Transfer-Encoding: 8bit\n"   "Content-Transfer-Encoding: 8bit\n"
− "Plural-Forms: nplurals=2; plural=(n != 1);\n" + "Plural-Forms: nplurals=2; plural=n != 1;\n"
  </code>   </code>
    



Ilic: Change "sum of" to "combination of" msgid and msgctxt.
2008-09-08T10:55:32Z
Change "sum of" to "combination of" msgid and msgctxt.

				
				
				
				
			
			← Older revision
			Revision as of 10:55, 8 September 2008
			
Line 277:
Line 277:
  </code>   </code>
    
− This is now a valid PO file, and you can translate each 'S' properly. By this we update the earlier approximation that messages must be unique by <tt>msgid</tt> strings: they must in fact be unique by the ''sum'' of <tt>msgctxt</tt> and <tt>msgid</tt> strings. If <tt>msgctxt</tt> string is missing, as it usually is, you can think of it as being present but empty. + This is now a valid PO file, and you can translate each 'S' properly. By this we update the earlier approximation that messages must be unique by <tt>msgid</tt> strings: they must in fact be unique by the ''combination'' of <tt>msgctxt</tt> and <tt>msgid</tt> strings. If <tt>msgctxt</tt> string is missing, as it usually is, you can think of it as being present but empty.
    
  A rather frequent example when disambiguating contexts are needed, is when the original text is a single English adjective, and used at several places in the source:   A rather frequent example when disambiguating contexts are needed, is when the original text is a single English adjective, and used at several places in the source:

← Older revision		Revision as of 16:00, 15 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Localization/Concepts/PO_Odyssey}}~~

	{{LocalizationBrowser\|		{{LocalizationBrowser\|