Localization/Tools/Pology/PO Embedded Diffing - Revision history

AnneW at 16:35, 17 July 2012

2012-07-17T16:35:14Z

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


2011-06-29T21:14:39Z
Text replace - "<code diff>" to "<syntaxhighlight lang="diff">"

				
				
				
				
			
			← Older revision
			Revision as of 21:14, 29 June 2011
			
Line 39:
Line 39:
  |style="padding-right: 0.5em; width: 1%"|'''diff'''   |style="padding-right: 0.5em; width: 1%"|'''diff'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code diff> + <syntaxhighlight lang="diff">
  ⁠  #: main.c:110   ⁠  #: main.c:110
  - #, fuzzy   - #, fuzzy



Neverendingo: Text replace - "" to ""

2011-06-29T21:12:45Z
Text replace - "<code text>" to "<syntaxhighlight lang="text">"

				
				
				
				
			
			← Older revision
			Revision as of 21:12, 29 June 2011
			
Line 81:
Line 81:
  |style="padding-right: 1em; width: 1%"|'''old'''   |style="padding-right: 1em; width: 1%"|'''old'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  "The Record of The Witch River"   "The Record of The Witch River"
  </syntaxhighlight>   </syntaxhighlight>
Line 87:
Line 87:
  |style="padding-right: 1em; width: 1%"|'''new'''   |style="padding-right: 1em; width: 1%"|'''new'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  "Records of The Witch River"   "Records of The Witch River"
  </syntaxhighlight>   </syntaxhighlight>
Line 93:
Line 93:
  |style="padding-right: 0.5em; width: 1%"|'''diff'''   |style="padding-right: 0.5em; width: 1%"|'''diff'''
  |style="padding-bottom: 1em"|   |style="padding-bottom: 1em"|
− <code text> + <syntaxhighlight lang="text">
  "[-The Record-]{+Records+} of The Witch River"   "[-The Record-]{+Records+} of The Witch River"
  </syntaxhighlight>   </syntaxhighlight>
Line 104:
Line 104:
  |style="padding-right: 1em; width: 1%"|'''old'''   |style="padding-right: 1em; width: 1%"|'''old'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  "The Record of The Witch River"   "The Record of The Witch River"
  </syntaxhighlight>   </syntaxhighlight>
Line 110:
Line 110:
  |style="padding-right: 1em; width: 1%"|'''new'''   |style="padding-right: 1em; width: 1%"|'''new'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  "Records of The Witch River"   "Records of The Witch River"
  </syntaxhighlight>   </syntaxhighlight>
Line 116:
Line 116:
  |style="padding-right: 0.5em; width: 1%"|'''ediff'''   |style="padding-right: 0.5em; width: 1%"|'''ediff'''
  |style="padding-bottom: 1em"|   |style="padding-bottom: 1em"|
− <code text> + <syntaxhighlight lang="text">
  "{-The Record-}{+Records+} of The Witch River"   "{-The Record-}{+Records+} of The Witch River"
  </syntaxhighlight>   </syntaxhighlight>
Line 127:
Line 127:
  |style="padding-right: 1em; width: 1%"|'''old'''   |style="padding-right: 1em; width: 1%"|'''old'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  "Foo {+ bar"   "Foo {+ bar"
  </syntaxhighlight>   </syntaxhighlight>
Line 133:
Line 133:
  |style="padding-right: 1em; width: 1%"|'''new'''   |style="padding-right: 1em; width: 1%"|'''new'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  "Foo {+ qwyx"   "Foo {+ qwyx"
  </syntaxhighlight>   </syntaxhighlight>
Line 139:
Line 139:
  |style="padding-right: 0.5em; width: 1%"|'''ediff'''   |style="padding-right: 0.5em; width: 1%"|'''ediff'''
  |style="padding-bottom: 1em"|   |style="padding-bottom: 1em"|
− <code text> + <syntaxhighlight lang="text">
  "Foo {~+ {-bar-}{+qwyx+}"   "Foo {~+ {-bar-}{+qwyx+}"
  </syntaxhighlight>   </syntaxhighlight>
Line 152:
Line 152:
  |style="padding-right: 1em; width: 1%"|'''old'''   |style="padding-right: 1em; width: 1%"|'''old'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  </syntaxhighlight>   </syntaxhighlight>
  |-   |-
  |style="padding-right: 1em; width: 1%"|'''new'''   |style="padding-right: 1em; width: 1%"|'''new'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  "a-context-note"   "a-context-note"
  </syntaxhighlight>   </syntaxhighlight>
Line 163:
Line 163:
  |style="padding-right: 0.5em; width: 1%"|'''ediff'''   |style="padding-right: 0.5em; width: 1%"|'''ediff'''
  |style="padding-bottom: 1em"|   |style="padding-bottom: 1em"|
− <code text> + <syntaxhighlight lang="text">
  "{+a-context-note+}~"   "{+a-context-note+}~"
  </syntaxhighlight>   </syntaxhighlight>
Line 172:
Line 172:
  How exactly the difference between two strings is formed, may be left to implementation. In fact, an implementation may allow translator to select between several diffing algorithms, depending on personal taste and situation. For example, the default algorithm of <tt>poediff</tt> does the following: words are diffed as whole, all non-word segments (interpunction, markup tags, etc.) character by character, and equal non-word segments between different words are taken into the difference segment. Hence the above ediff   How exactly the difference between two strings is formed, may be left to implementation. In fact, an implementation may allow translator to select between several diffing algorithms, depending on personal taste and situation. For example, the default algorithm of <tt>poediff</tt> does the following: words are diffed as whole, all non-word segments (interpunction, markup tags, etc.) character by character, and equal non-word segments between different words are taken into the difference segment. Hence the above ediff
    
− <code text> + <syntaxhighlight lang="text">
  "{-The Record-}{+Records+} of The Witch River"   "{-The Record-}{+Records+} of The Witch River"
  </syntaxhighlight>   </syntaxhighlight>
Line 178:
Line 178:
  instead of smaller   instead of smaller
    
− <code text> + <syntaxhighlight lang="text">
  "{-The -}Record{+s+} of The Witch River"   "{-The -}Record{+s+} of The Witch River"
  </syntaxhighlight>   </syntaxhighlight>
Line 300:
Line 300:
  |style="padding-right: 1em; width: 1%"|'''old'''   |style="padding-right: 1em; width: 1%"|'''old'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  fuzzy                   -->     fuzzy   fuzzy                   -->     fuzzy
  old-previous-fields     -->     old-previous-fields   old-previous-fields     -->     old-previous-fields
Line 309:
Line 309:
  |style="padding-right: 1em; width: 1%"|'''new'''   |style="padding-right: 1em; width: 1%"|'''new'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  -                       -->     -   -                       -->     -
  -                       -->     old-current-fields   -                       -->     old-current-fields
Line 357:
Line 357:
  |style="padding-right: 1em; width: 1%"|'''old'''   |style="padding-right: 1em; width: 1%"|'''old'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  -                       -->     -   -                       -->     -
  -                       -->     new-previous-fields   -                       -->     new-previous-fields
Line 366:
Line 366:
  |style="padding-right: 1em; width: 1%"|'''new'''   |style="padding-right: 1em; width: 1%"|'''new'''
  |style="padding-bottom: 0.5em"|   |style="padding-bottom: 0.5em"|
− <code text> + <syntaxhighlight lang="text">
  fuzzy                   -->     fuzzy   fuzzy                   -->     fuzzy
  new-previous-fields     -->     new-current-fields   new-previous-fields     -->     new-current-fields
Line 580:
Line 580:
  * That a particular message in the ediff PO is a header ediff, is indicated by the <tt>msgctxt</tt> set to a special value, here a single tilde. This value is given up front by the <tt>X-Ediff-Header-Context</tt> of the ediff PO header. It should be computed during diffing such that it does not conflict with <tt>msgctxt</tt> of one of the normal message ediffs (e.g. it may simply be a sufficiently long sequence tildes).   * That a particular message in the ediff PO is a header ediff, is indicated by the <tt>msgctxt</tt> set to a special value, here a single tilde. This value is given up front by the <tt>X-Ediff-Header-Context</tt> of the ediff PO header. It should be computed during diffing such that it does not conflict with <tt>msgctxt</tt> of one of the normal message ediffs (e.g. it may simply be a sufficiently long sequence tildes).
    
− * The <tt>msgid</tt> field of the header ediff contains newline-separated paths of the diffed PO files. More precisely, the two lines of the <tt>msgid</tt> field are in form <code text>[+-] file-path[ <<< comment]\n</syntaxhighlight> (The trailing newline of the second file path is elided if the <tt>msgstr</tt> does not end in newline, to prevent <tt>msgfmt</tt> from complaining.) The optional, &lt;&lt;&lt;-separated comment to the file path can be used for any purpose, one which will be demonstrated when describing functionality of <tt>poediff</tt>. + * The <tt>msgid</tt> field of the header ediff contains newline-separated paths of the diffed PO files. More precisely, the two lines of the <tt>msgid</tt> field are in form <syntaxhighlight lang="text">[+-] file-path[ <<< comment]\n</syntaxhighlight> (The trailing newline of the second file path is elided if the <tt>msgstr</tt> does not end in newline, to prevent <tt>msgfmt</tt> from complaining.) The optional, &lt;&lt;&lt;-separated comment to the file path can be used for any purpose, one which will be demonstrated when describing functionality of <tt>poediff</tt>.
    
  Although when a PO file is properly updated there should always be some difference in its header, it may happen that there is none. In such case, the header ediff message is still added, but such that it only contains the extra decorations -- the visual separator comment, special <tt>msgctxt</tt>, and <tt>msgid</tt> with file paths. All other comments and <tt>msgstr</tt> should be empty, and the empty <tt>msgstr</tt> indicates that there was no difference in headers. Presence of this "empty" header ediff is necessary to provide diffed file paths and, if several POs were diffed, to separate them in the ediff PO.   Although when a PO file is properly updated there should always be some difference in its header, it may happen that there is none. In such case, the header ediff message is still added, but such that it only contains the extra decorations -- the visual separator comment, special <tt>msgctxt</tt>, and <tt>msgid</tt> with file paths. All other comments and <tt>msgstr</tt> should be empty, and the empty <tt>msgstr</tt> indicates that there was no difference in headers. Presence of this "empty" header ediff is necessary to provide diffed file paths and, if several POs were diffed, to separate them in the ediff PO.





Neverendingo: Text replace - "" to ""

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


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


Neverendingo: Text replace - "" to ""

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

				
				
				
				
			
			← Older revision
			Revision as of 20:42, 29 June 2011
			
Line 617:
Line 617:
  Pology's <tt>poediff</tt> script implements embedded diffing as outlined in the previous section. To diff two PO files, executing the usual:   Pology's <tt>poediff</tt> script implements embedded diffing as outlined in the previous section. To diff two PO files, executing the usual:
    
− <code bash> + <syntaxhighlight lang="bash">
  $ poediff orig/foo.po mod/foo.po   $ poediff orig/foo.po mod/foo.po
  </code>   </code>
Line 625:
Line 625:
  It is equally simple to make ediff of directories:   It is equally simple to make ediff of directories:
    
− <code bash> + <syntaxhighlight lang="bash">
  $ poediff orig/ mod/   $ poediff orig/ mod/
  </code>   </code>
Line 648:
Line 648:
  When PO files are under version control, <tt>poediff</tt> can operate in VCS mode using the option <tt>-c VCSKEY</tt> (<tt>--vcs</tt>), where <tt>VCSKEY</tt> is the keyword of one of VCS known to <tt>poediff</tt>. Then, instead of giving two paths to diff, any number of version-controlled paths (files or directories) is given. Without other options, all modified PO files in these paths are diffed against the last commit known to local repository. For example, if an application uses Subversion repository, PO files in its <tt>po/</tt> directory can be diffed with:   When PO files are under version control, <tt>poediff</tt> can operate in VCS mode using the option <tt>-c VCSKEY</tt> (<tt>--vcs</tt>), where <tt>VCSKEY</tt> is the keyword of one of VCS known to <tt>poediff</tt>. Then, instead of giving two paths to diff, any number of version-controlled paths (files or directories) is given. Without other options, all modified PO files in these paths are diffed against the last commit known to local repository. For example, if an application uses Subversion repository, PO files in its <tt>po/</tt> directory can be diffed with:
    
− <code bash> + <syntaxhighlight lang="bash">
  $ poediff -c svn app/po/   $ poediff -c svn app/po/
  </code>   </code>
Line 676:
Line 676:
  Command-line interface of <tt>poepatch</tt> is much like <tt>patch(1)</tt>, sans the myriad of its more obscure options. There is the <tt>-p</tt> option to strip leading elements of file paths in the ediff, and <tt>-d</tt> option to append to them a directory path where target POs are to be found. If the files were diffed with underlying VCS as in the previous example, then the ediff could be applied in any of the following ways:   Command-line interface of <tt>poepatch</tt> is much like <tt>patch(1)</tt>, sans the myriad of its more obscure options. There is the <tt>-p</tt> option to strip leading elements of file paths in the ediff, and <tt>-d</tt> option to append to them a directory path where target POs are to be found. If the files were diffed with underlying VCS as in the previous example, then the ediff could be applied in any of the following ways:
    
− <code bash> + <syntaxhighlight lang="bash">
  $ cd repos/app/po && poepatch <ediff.po   $ cd repos/app/po && poepatch <ediff.po
  $ cd repos/ && poepatch -p0 <ediff.po   $ cd repos/ && poepatch -p0 <ediff.po
Line 818:
Line 818:
  A patch is applied with embedding by issuing the <tt>-e</tt> (<tt>--embed</tt>) option (<tt>E</tt> in parenthesis in progress output indicates that embedding is engaged):   A patch is applied with embedding by issuing the <tt>-e</tt> (<tt>--embed</tt>) option (<tt>E</tt> in parenthesis in progress output indicates that embedding is engaged):
    
− <code bash> + <syntaxhighlight lang="bash">
  $ poepatch -e <ediff.po   $ poepatch -e <ediff.po
  patched (E): lang.po   patched (E): lang.po
Line 826:
Line 826:
  When the patched PO has been reviewed and patched messages possibly edited, all remaining embedded differences are removed, i.e. resolved to new versions, by running:   When the patched PO has been reviewed and patched messages possibly edited, all remaining embedded differences are removed, i.e. resolved to new versions, by running:
    
− <code bash> + <syntaxhighlight lang="bash">
  $ poepatch -u lang.po   $ poepatch -u lang.po
  </code>   </code>
Line 852:
Line 852:
  In short, full embedded diffing is too heavyweight as an assist to updating fuzzy messages. Instead, there is a Pology sieve intended for this particular purpose, <tt>diff-previous</tt>, which embeds the difference from previous to current original text into previous fields. Executing:   In short, full embedded diffing is too heavyweight as an assist to updating fuzzy messages. Instead, there is a Pology sieve intended for this particular purpose, <tt>diff-previous</tt>, which embeds the difference from previous to current original text into previous fields. Executing:
    
− <code bash> + <syntaxhighlight lang="bash">
  $ posieve diff-previous lang.po   $ posieve diff-previous lang.po
  </code>   </code>
Line 870:
Line 870:
  Note that no embedding should remain in previous fields by the time the catalog is merged again, as it would throw off <tt>msgmerge</tt> when matching to create new fuzzies. This will normally not be an issue, as the translator will have unfuzzied all messages when updating the catalog after last merging. However, if there were a lot of fuzzy messages, and translator didn't have the time to update all of them, <tt>diff-previous</tt> sieve can also be used to unembed any remaining ediffs, restoring the original values of previous fields. It just needs to be run on the catalog with extra parameter <tt>strip</tt>:   Note that no embedding should remain in previous fields by the time the catalog is merged again, as it would throw off <tt>msgmerge</tt> when matching to create new fuzzies. This will normally not be an issue, as the translator will have unfuzzied all messages when updating the catalog after last merging. However, if there were a lot of fuzzy messages, and translator didn't have the time to update all of them, <tt>diff-previous</tt> sieve can also be used to unembed any remaining ediffs, restoring the original values of previous fields. It just needs to be run on the catalog with extra parameter <tt>strip</tt>:
    
− <code bash> + <syntaxhighlight lang="bash">
  $ posieve diff-previous -sstrip lang.po   $ posieve diff-previous -sstrip lang.po
  </code>   </code>



Neverendingo: Text replace - "" to ""

2011-06-29T20:38:27Z
Text replace - "<code ini>" to "<syntaxhighlight lang="ini">"

				
				
				
				
			
			← Older revision
			Revision as of 20:38, 29 June 2011
			
Line 633:
Line 633:
  To have non-dummy translator name and email address added to the header of ediff PO, set them in Pology's configuration file, <tt>~/.pologyrc</tt>:   To have non-dummy translator name and email address added to the header of ediff PO, set them in Pology's configuration file, <tt>~/.pologyrc</tt>:
    
− <code ini> + <syntaxhighlight lang="ini">
  [user]   [user]
  name = Koja Kojic   name = Koja Kojic



Ilic: Wording.
2010-06-13T08:27:44Z
Wording.

				
				
				
				
			
			← Older revision
			Revision as of 08:27, 13 June 2010
			
Line 846:
Line 846:
  </code>   </code>
    
− Obviously, a dedicated PO editor could automatically present appropriate diff for messages like these (e.g. [[Localization/Tools/Lokalize|Lokalize]] can do it since introduction), so for translators using such an editor, diffing of fuzzies is either already available or a strong candidate for a feature request. The rest of this section therefore applies only to translators who stick to general text editors (with or without some power-assists for editing PO files). + Obviously, a dedicated PO editor could automatically present appropriate diff for messages like these (e.g. [[Localization/Tools/Lokalize|Lokalize]] can do it since inception), so for translators using such an editor, diffing of fuzzies is either already available or a strong candidate for a feature request. The rest of this section therefore applies only to translators who stick to general text editors (with or without some power-assists for editing PO files).
    
  One ''could'' use <tt>poediff</tt> and <tt>poepatch</tt> for the purpose of diffing of fuzzies, by first diffing from previous complete to new merged catalog, embedding the patch into the merged catalog, updating translation, and then unembedding ediffs. One drawback of this, however, is that two version of the catalog are necessary, when only the merged one contains all the information. More drawbacks are that the catalog has to be cleared of ediffs after updating, or that each diffed message contains more information than necessary (<tt>ediff</tt> flag, <tt>#. ediff:</tt> comment) since all ediffs are of one and the same type.   One ''could'' use <tt>poediff</tt> and <tt>poepatch</tt> for the purpose of diffing of fuzzies, by first diffing from previous complete to new merged catalog, embedding the patch into the merged catalog, updating translation, and then unembedding ediffs. One drawback of this, however, is that two version of the catalog are necessary, when only the merged one contains all the information. More drawbacks are that the catalog has to be cleared of ediffs after updating, or that each diffed message contains more information than necessary (<tt>ediff</tt> flag, <tt>#. ediff:</tt> comment) since all ediffs are of one and the same type.



Ilic: Example corrected: do not remove, but change ediff-to-new to ediff.
2010-06-13T08:26:31Z
Example corrected: do not remove, but change ediff-to-new to ediff.

				
				
				
				
			
			← Older revision
			Revision as of 08:26, 13 June 2010
			
Line 774:
Line 774:
  #. ediff: state {-fuzzy-}   #. ediff: state {-fuzzy-}
  #: tools/power.c:361   #: tools/power.c:361
  + #, ediff
  msgid "Active sonar {-low-}{+high+} frequency:"   msgid "Active sonar {-low-}{+high+} frequency:"
  msgstr "{-Niska-}{+Visoka+} frekvencija aktivnog sonara"   msgstr "{-Niska-}{+Visoka+} frekvencija aktivnog sonara"
  </code>   </code>
    
− Given that the file of rejected ediffs is also an ediff PO, after edits to make some of the rejected patches applicable, it can be ''reapplied'' as patch. If that is done, <tt>poepatch</tt> will silently ignore all ediff messages having <tt>ediff-no-match</tt> and <tt>ediff-to-new</tt> flag, as these have already been determined inapplicable. That is why the reviewer had removed the <tt>ediff-to-new</tt> flag from the folded ediff above. + Given that the file of rejected ediffs is also an ediff PO, after edits to make some of the rejected patches applicable, it can be ''reapplied'' as patch. If that is done, <tt>poepatch</tt> will silently ignore all ediff messages having <tt>ediff-no-match</tt> and <tt>ediff-to-new</tt> flag, as these have already been determined inapplicable. That is why in the example above the reviewer has replaced the <tt>ediff-to-new</tt> with the plain <tt>ediff</tt> flag on the folded ediff.
    
  === Embedding Patches ===   === Embedding Patches ===



Ilic: Lightweight diffing for updating fuzzies.
2009-02-17T15:50:04Z
Lightweight diffing for updating fuzzies.

				
				
				
				
			
			← Older revision
			Revision as of 15:50, 17 February 2009
			
Line 832:
Line 832:
    
  What happens with rejected patches when embedding is engaged? They are also added into the target PO, with heuristic positioning, and no separate ediff PO with rejects is created. Same as with plain patching, straight-out rejects will have <tt>ediff-no-match</tt> flag, and split rejects <tt>ediff-to-cur</tt> and <tt>ediff-to-new</tt>. If these are not manually resolved during the review (<tt>ediff-no-match</tt> messages removed, <tt>ediff-to-*</tt> messages removed or folded), when <tt>poepatch</tt> is run to unembed the patch, it will remove all <tt>ediff-no-match</tt> and <tt>ediff-to-new</tt> messages, and resolve <tt>ediff-to-cur</tt> messages to new version (effectively rejecting patches from which split rejects had originated).   What happens with rejected patches when embedding is engaged? They are also added into the target PO, with heuristic positioning, and no separate ediff PO with rejects is created. Same as with plain patching, straight-out rejects will have <tt>ediff-no-match</tt> flag, and split rejects <tt>ediff-to-cur</tt> and <tt>ediff-to-new</tt>. If these are not manually resolved during the review (<tt>ediff-no-match</tt> messages removed, <tt>ediff-to-*</tt> messages removed or folded), when <tt>poepatch</tt> is run to unembed the patch, it will remove all <tt>ediff-no-match</tt> and <tt>ediff-to-new</tt> messages, and resolve <tt>ediff-to-cur</tt> messages to new version (effectively rejecting patches from which split rejects had originated).
  + 
  + == Lightweight Diffing when Updating Translation ==
  + 
  + Rather than for reviewing changes and sending patches, the translator may want to have only a convenient diff between the previous and new original text when updating a catalog merged with <tt>--previous</tt> option. Repeating the (by now) usual example message:
  + 
  + <code po>
  + #: main.c:110
  + #, fuzzy
  + #| msgid "The Record of The Witch River"
  + msgid "Records of The Witch River"
  + msgstr "Beleška o Veštičjoj reci"
  + </code>
  + 
  + Obviously, a dedicated PO editor could automatically present appropriate diff for messages like these (e.g. [[Localization/Tools/Lokalize|Lokalize]] can do it since introduction), so for translators using such an editor, diffing of fuzzies is either already available or a strong candidate for a feature request. The rest of this section therefore applies only to translators who stick to general text editors (with or without some power-assists for editing PO files).
  + 
  + One ''could'' use <tt>poediff</tt> and <tt>poepatch</tt> for the purpose of diffing of fuzzies, by first diffing from previous complete to new merged catalog, embedding the patch into the merged catalog, updating translation, and then unembedding ediffs. One drawback of this, however, is that two version of the catalog are necessary, when only the merged one contains all the information. More drawbacks are that the catalog has to be cleared of ediffs after updating, or that each diffed message contains more information than necessary (<tt>ediff</tt> flag, <tt>#. ediff:</tt> comment) since all ediffs are of one and the same type.
  + 
  + In short, full embedded diffing is too heavyweight as an assist to updating fuzzy messages. Instead, there is a Pology sieve intended for this particular purpose, <tt>diff-previous</tt>, which embeds the difference from previous to current original text into previous fields. Executing:
  + 
  + <code bash>
  + $ posieve diff-previous lang.po
  + </code>
  + 
  + will modify fuzzy messages in-place in the processed catalog, to the following partial ediff:
  + 
  + <code po>
  + #: main.c:110
  + #, fuzzy
  + #| msgid "{-The Record-}{+Records+} of The Witch River"
  + msgid "Records of The Witch River"
  + msgstr "Beleška o Veštičjoj reci"
  + </code>
  + 
  + The format of embedding is the same as before, so the ediff-aware syntax highlighting works here too. When the message is updated and properly unfuzzied (both <tt>fuzzy</tt> flag and previous fields removed), none of the ediff remains, so there is no need for post-unembedding. In other words, translator updates translation just as used to before, with the free benefit of having the ediff of original text.
  + 
  + Note that no embedding should remain in previous fields by the time the catalog is merged again, as it would throw off <tt>msgmerge</tt> when matching to create new fuzzies. This will normally not be an issue, as the translator will have unfuzzied all messages when updating the catalog after last merging. However, if there were a lot of fuzzy messages, and translator didn't have the time to update all of them, <tt>diff-previous</tt> sieve can also be used to unembed any remaining ediffs, restoring the original values of previous fields. It just needs to be run on the catalog with extra parameter <tt>strip</tt>:
  + 
  + <code bash>
  + $ posieve diff-previous -sstrip lang.po
  + </code>

← Older revision		Revision as of 16:35, 17 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Localization/Tools/Pology/PO_Embedded_Diffing}}~~	+

	{{LocalizationBrowser\|		{{LocalizationBrowser\|

← Older revision		Revision as of 15:50, 17 February 2009
Line 832:		Line 832:

	What happens with rejected patches when embedding is engaged? They are also added into the target PO, with heuristic positioning, and no separate ediff PO with rejects is created. Same as with plain patching, straight-out rejects will have <tt>ediff-no-match</tt> flag, and split rejects <tt>ediff-to-cur</tt> and <tt>ediff-to-new</tt>. If these are not manually resolved during the review (<tt>ediff-no-match</tt> messages removed, <tt>ediff-to-*</tt> messages removed or folded), when <tt>poepatch</tt> is run to unembed the patch, it will remove all <tt>ediff-no-match</tt> and <tt>ediff-to-new</tt> messages, and resolve <tt>ediff-to-cur</tt> messages to new version (effectively rejecting patches from which split rejects had originated).		What happens with rejected patches when embedding is engaged? They are also added into the target PO, with heuristic positioning, and no separate ediff PO with rejects is created. Same as with plain patching, straight-out rejects will have <tt>ediff-no-match</tt> flag, and split rejects <tt>ediff-to-cur</tt> and <tt>ediff-to-new</tt>. If these are not manually resolved during the review (<tt>ediff-no-match</tt> messages removed, <tt>ediff-to-*</tt> messages removed or folded), when <tt>poepatch</tt> is run to unembed the patch, it will remove all <tt>ediff-no-match</tt> and <tt>ediff-to-new</tt> messages, and resolve <tt>ediff-to-cur</tt> messages to new version (effectively rejecting patches from which split rejects had originated).
		+
		+	== Lightweight Diffing when Updating Translation ==
		+
		+	Rather than for reviewing changes and sending patches, the translator may want to have only a convenient diff between the previous and new original text when updating a catalog merged with <tt>--previous</tt> option. Repeating the (by now) usual example message:
		+
		+	<code po>
		+	#: main.c:110
		+	#, fuzzy
		+	#\| msgid "The Record of The Witch River"
		+	msgid "Records of The Witch River"
		+	msgstr "Beleška o Veštičjoj reci"
		+	</code>
		+
		+	Obviously, a dedicated PO editor could automatically present appropriate diff for messages like these (e.g. [[Localization/Tools/Lokalize\|Lokalize]] can do it since introduction), so for translators using such an editor, diffing of fuzzies is either already available or a strong candidate for a feature request. The rest of this section therefore applies only to translators who stick to general text editors (with or without some power-assists for editing PO files).
		+
		+	One ''could'' use <tt>poediff</tt> and <tt>poepatch</tt> for the purpose of diffing of fuzzies, by first diffing from previous complete to new merged catalog, embedding the patch into the merged catalog, updating translation, and then unembedding ediffs. One drawback of this, however, is that two version of the catalog are necessary, when only the merged one contains all the information. More drawbacks are that the catalog has to be cleared of ediffs after updating, or that each diffed message contains more information than necessary (<tt>ediff</tt> flag, <tt>#. ediff:</tt> comment) since all ediffs are of one and the same type.
		+
		+	In short, full embedded diffing is too heavyweight as an assist to updating fuzzy messages. Instead, there is a Pology sieve intended for this particular purpose, <tt>diff-previous</tt>, which embeds the difference from previous to current original text into previous fields. Executing:
		+
		+	<code bash>
		+	$ posieve diff-previous lang.po
		+	</code>
		+
		+	will modify fuzzy messages in-place in the processed catalog, to the following partial ediff:
		+
		+	<code po>
		+	#: main.c:110
		+	#, fuzzy
		+	#\| msgid "{-The Record-}{+Records+} of The Witch River"
		+	msgid "Records of The Witch River"
		+	msgstr "Beleška o Veštičjoj reci"
		+	</code>
		+
		+	The format of embedding is the same as before, so the ediff-aware syntax highlighting works here too. When the message is updated and properly unfuzzied (both <tt>fuzzy</tt> flag and previous fields removed), none of the ediff remains, so there is no need for post-unembedding. In other words, translator updates translation just as used to before, with the free benefit of having the ediff of original text.
		+
		+	Note that no embedding should remain in previous fields by the time the catalog is merged again, as it would throw off <tt>msgmerge</tt> when matching to create new fuzzies. This will normally not be an issue, as the translator will have unfuzzied all messages when updating the catalog after last merging. However, if there were a lot of fuzzy messages, and translator didn't have the time to update all of them, <tt>diff-previous</tt> sieve can also be used to unembed any remaining ediffs, restoring the original values of previous fields. It just needs to be run on the catalog with extra parameter <tt>strip</tt>:
		+
		+	<code bash>
		+	$ posieve diff-previous -sstrip lang.po
		+	</code>