Localization/Workflows/PO Ascription - Revision history

AnneW at 15:19, 19 July 2012

2012-07-19T15:19:02Z

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


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

				
				
				
				
			
			← Older revision
			Revision as of 21:12, 29 June 2011
			
Line 58:
Line 58:
  The summit branch for the language <tt>LANG</tt> is positioned like this in the KDE repository:   The summit branch for the language <tt>LANG</tt> is positioned like this in the KDE repository:
    
− <code text> + <syntaxhighlight lang="text">
  $KDEREPO/   $KDEREPO/
       trunk/        trunk/
Line 70:
Line 70:
  The team coordinator already has this part of the repository tree locally due to regular summit operations. For the same reason Pology is already set up. Setting up the ascription system is now simple. The file <tt>ascription-config</tt> is created in the parent directory of the summit:   The team coordinator already has this part of the repository tree locally due to regular summit operations. For the same reason Pology is already set up. Setting up the ascription system is now simple. The file <tt>ascription-config</tt> is created in the parent directory of the summit:
    
− <code text> + <syntaxhighlight lang="text">
  ...   ...
       LANG/        LANG/
Line 81:
Line 81:
  with the following contents:   with the following contents:
    
− <code text> + <syntaxhighlight lang="text">
  # ---------------------------   # ---------------------------
  # Global ascription settings.   # Global ascription settings.
Line 154:
Line 154:
  When the <tt>poascribe</tt> command is issued, a progress bar will appear, and the following output will start to unfold:   When the <tt>poascribe</tt> command is issued, a progress bar will appear, and the following output will start to unfold:
    
− <code text> + <syntaxhighlight lang="text">
  LANG/summit/messages/extragear-base/rellinks.po  (50/50)   LANG/summit/messages/extragear-base/rellinks.po  (50/50)
  LANG/summit/messages/extragear-base/autorefresh.po  (13/13)   LANG/summit/messages/extragear-base/autorefresh.po  (13/13)
Line 183:
Line 183:
  After the initial ascription has been made, the ascription tree will appear next to the summit tree. This tree will contain one ascription PO file for each summit PO file, with the same name and relative location within the tree:   After the initial ascription has been made, the ascription tree will appear next to the summit tree. This tree will contain one ascription PO file for each summit PO file, with the same name and relative location within the tree:
    
− <code text> + <syntaxhighlight lang="text">
  ...   ...
       LANG/        LANG/
Line 220:
Line 220:
  In order not to have to issue their own user name (<tt>-u</tt> option to <tt>poascribe</tt>) all the time, translators can set it in Pology user configuration <tt>~/.pologyrc</tt>, in <tt>[poascribe]</tt> section:   In order not to have to issue their own user name (<tt>-u</tt> option to <tt>poascribe</tt>) all the time, translators can set it in Pology user configuration <tt>~/.pologyrc</tt>, in <tt>[poascribe]</tt> section:
    
− <code text> + <syntaxhighlight lang="text">
  [poascribe]   [poascribe]
  user = alice   user = alice
Line 391:
Line 391:
  <tt>poascribe</tt> can support this scenario in the following way. A ''review type'' tag for language style is defined in the ascription configuration, using the <tt>review-tags</tt> field:   <tt>poascribe</tt> can support this scenario in the following way. A ''review type'' tag for language style is defined in the ascription configuration, using the <tt>review-tags</tt> field:
    
− <code text> + <syntaxhighlight lang="text">
  [global]   [global]
  ...   ...
Line 413:
Line 413:
  If Dan is always going to review the language style, in order not to have to issue the selector and tag in the command line all the time, he can make them default per mode in <tt>~/.pologyrc</tt>:   If Dan is always going to review the language style, in order not to have to issue the selector and tag in the command line all the time, he can make them default per mode in <tt>~/.pologyrc</tt>:
    
− <code text> + <syntaxhighlight lang="text">
  [poascribe]   [poascribe]
  user = dan   user = dan
Line 480:
Line 480:
  Each top level PO tree has its own summit configuration file, named <tt>MSGTREE.extras.summit</tt>:   Each top level PO tree has its own summit configuration file, named <tt>MSGTREE.extras.summit</tt>:
    
− <code text> + <syntaxhighlight lang="text">
  ...   ...
       LANG/        LANG/



Neverendingo: Text replace - "" to ""

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

				
				
				
				
			
			← Older revision
			Revision as of 21:09, 29 June 2011
			
Line 277:
Line 277:
  Unreviewed messages have now been marked and diffed, inside the listed PO files. What is this about "diffing"? If the files had already been reviewed before, some of the messages modified since then (those marked for review) may have changed very little (e.g. a few words in a paragraph-length message, or even just punctuation). Therefore, for each message marked for review, Alice also wants to see the diff since last review to current version. Here are two messages in typical review states added by <tt>poascribe di</tt>:   Unreviewed messages have now been marked and diffed, inside the listed PO files. What is this about "diffing"? If the files had already been reviewed before, some of the messages modified since then (those marked for review) may have changed very little (e.g. a few words in a paragraph-length message, or even just punctuation). Therefore, for each message marked for review, Alice also wants to see the diff since last review to current version. Here are two messages in typical review states added by <tt>poascribe di</tt>:
    
− <code po> + <syntaxhighlight lang="text">
  #. +> trunk stable   #. +> trunk stable
  #. ascto: charlie:m   #. ascto: charlie:m
Line 424:
Line 424:
  The important point of review tags is that they make reviews by types independent. For example, Dan may come around to review the language style of the given message after several modifications and general reviews have been ascribed to it -- <tt>modar:::lstyle</tt> will simply ignore all reviews except for <tt>lstyle</tt> reviews. This is going to be reflected in the <tt>ascto:</tt> comment to marked messages:   The important point of review tags is that they make reviews by types independent. For example, Dan may come around to review the language style of the given message after several modifications and general reviews have been ascribed to it -- <tt>modar:::lstyle</tt> will simply ignore all reviews except for <tt>lstyle</tt> reviews. This is going to be reflected in the <tt>ascto:</tt> comment to marked messages:
    
− <code po> + <syntaxhighlight lang="text">
  #...   #...
  #. ascto: charlie:m alice:r bob:m   #. ascto: charlie:m alice:r bob:m
Line 434:
Line 434:
  Here Alice has made one review between Charlie's and Bob's modifications, and that review, being general instead of <tt>lstyle</tt>, did not cause <tt>modar</tt> to stop at it. After Dan reviews this message for language style, Alice runs selection for review and gets this:   Here Alice has made one review between Charlie's and Bob's modifications, and that review, being general instead of <tt>lstyle</tt>, did not cause <tt>modar</tt> to stop at it. After Dan reviews this message for language style, Alice runs selection for review and gets this:
    
− <code po> + <syntaxhighlight lang="text">
  #...   #...
  #. ascto: bob:m dan:r(lstyle)   #. ascto: bob:m dan:r(lstyle)



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


Neverendingo: Text replace - "" to ""

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

				
				
				
				
			
			← Older revision
			Revision as of 20:48, 29 June 2011
			
Line 137:
Line 137:
  The most common situation at start of ascription workflow is that there already exists a body of translations, contributed to by many different people over time. The coordinator should ascribe all existing translations as initial modifications, but to whom? It cannot be said precisely who translated what. The solution is to introduce a generic user in <tt>ascription-config</tt>, suitably known as "Unknown Hero" (or "Lost Translator", you can be inventive):   The most common situation at start of ascription workflow is that there already exists a body of translations, contributed to by many different people over time. The coordinator should ascribe all existing translations as initial modifications, but to whom? It cannot be said precisely who translated what. The solution is to introduce a generic user in <tt>ascription-config</tt>, suitably known as "Unknown Hero" (or "Lost Translator", you can be inventive):
    
− <code> + <syntaxhighlight lang="text">
  [user-uhero]   [user-uhero]
  name = Unknown Hero   name = Unknown Hero



Neverendingo: Text replace - "" to ""

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


Neverendingo: Text replace - "" to ""

2011-06-29T20:34:46Z
Text replace - "<code python>" to "<syntaxhighlight lang="python">"

				
				
				
				
			
			← Older revision
			Revision as of 20:34, 29 June 2011
			
Line 492:
Line 492:
  For the simple case of all reviews being general reviews, the filter is added to summit configuration like this (anywhere within <tt>*.extras.summit</tt> file):   For the simple case of all reviews being general reviews, the filter is added to summit configuration like this (anywhere within <tt>*.extras.summit</tt> file):
    
− <code python> + <syntaxhighlight lang="python">
  S.ascription_filters = [   S.ascription_filters = [
       ("regular", ["nmodar"]),        ("regular", ["nmodar"]),
Line 504:
Line 504:
  Why did we have to name the filter <tt>regular</tt>? (Those knowing some Python will also notice that it is defined as a list element.) Because it is possible to define more than one filter, and select which one is used on each scattering. For example, the coordinator may wish that, when the release is near and time is short to review everything, messages from a few experienced translators can be passed into release without review. If those translators are Alice and Bob, an "emergency" filter can be defined like this:   Why did we have to name the filter <tt>regular</tt>? (Those knowing some Python will also notice that it is defined as a list element.) Because it is possible to define more than one filter, and select which one is used on each scattering. For example, the coordinator may wish that, when the release is near and time is short to review everything, messages from a few experienced translators can be passed into release without review. If those translators are Alice and Bob, an "emergency" filter can be defined like this:
    
− <code python> + <syntaxhighlight lang="python">
  S.ascription_filters = [   S.ascription_filters = [
       ("regular", ["nmodar"]),        ("regular", ["nmodar"]),
Line 520:
Line 520:
  What if several selectors are needed to pass the message? For example, the language style review (the earlier example with Alice and Dan) too may be requested for regular scattering, but omitted from emergency scattering. The filter setup for this scenario looks like this:   What if several selectors are needed to pass the message? For example, the language style review (the earlier example with Alice and Dan) too may be requested for regular scattering, but omitted from emergency scattering. The filter setup for this scenario looks like this:
    
− <code python> + <syntaxhighlight lang="python">
  S.ascription_filters = [   S.ascription_filters = [
       ("regular", ["nmodar", "nmodar:::lstyle"]),        ("regular", ["nmodar", "nmodar:::lstyle"]),



Ilic: Fixed some leftovers of previous modifications.
2010-08-02T19:10:33Z
Fixed some leftovers of previous modifications.

				
				
				
				
			
			← Older revision
			Revision as of 19:10, 2 August 2010
			
Line 325:
Line 325:
  Three things have happened here. First, all review states (flags, embedded diffs, etc.) have been removed, restoring the PO file to normal. Then, any modifications that Alice have made during review are ascribed to her (here 3 out of 21 messages). Finally, all marked messages are ascribed as reviewed by Alice (any with <tt>unreviewed</tt>/<tt>nrev</tt> flags would have been omitted here). When committing, the only summit catalog that got committed is the one with modifications made during review, and all the ascription catalogs were committed because of the reviews recorded in them.   Three things have happened here. First, all review states (flags, embedded diffs, etc.) have been removed, restoring the PO file to normal. Then, any modifications that Alice have made during review are ascribed to her (here 3 out of 21 messages). Finally, all marked messages are ascribed as reviewed by Alice (any with <tt>unreviewed</tt>/<tt>nrev</tt> flags would have been omitted here). When committing, the only summit catalog that got committed is the one with modifications made during review, and all the ascription catalogs were committed because of the reviews recorded in them.
    
− When many files with few changes in each are to be reviewed, it becomes burdensome to manually open each and every diffed for review, and then to make sure that all are committed with <tt>poascribe ci</tt>. To make this easier, <tt>-w torevivew.out</tt> option can be added to <tt>poascribe di</tt>, which requests that paths of all diffed PO files are written into <tt>torevivew.out</tt> file. This file can then be used to batch open POs for review in the editor, as well as fed back on <tt>poascribe re</tt> with <tt>-f torevivew.out</tt>. There is also the <tt>-o</tt> option which causes <tt>poascribe</tt> to directly open PO files in a PO editor (though this is currently applicable only to Lokalize). Putting it together, to efficiently review a whole bunch of small changes throughout many files, Alice can: + When many files with few changes in each are to be reviewed, it becomes burdensome to manually open each and every diffed for review, and then to make sure that all are committed with <tt>poascribe ci</tt>. To make this easier, <tt>-w torevivew.out</tt> option can be added to <tt>poascribe di</tt>, which requests that paths of all diffed PO files are written into <tt>torevivew.out</tt> file. This file can then be used to batch open POs for review in the editor, as well as fed back on <tt>poascribe ci</tt> with <tt>-f torevivew.out</tt>. There is also the <tt>-o</tt> option which causes <tt>poascribe</tt> to directly open PO files in a PO editor (though this is currently applicable only to Lokalize). Putting it together, to efficiently review a whole bunch of small changes throughout many files, Alice can:
    
  <code bash>   <code bash>
Line 476:
Line 476:
  == Filtering for Release ==   == Filtering for Release ==
    
− The last component of the ascription system is how to prevent insufficiently reviewed messages from leaking into a release. In context of Pology and summit workflow, <tt>poascribe</tt> itself is used directly to this end. Instead, in the summit configuration (as opposed to ascription configuration), the team coordinator defines filters which pass messages by applying selectors. + The last component of the ascription system is how to prevent insufficiently reviewed messages from leaking into a release. In context of Pology and summit workflow, <tt>poascribe</tt> itself is not used directly to this end. Instead, in the summit configuration (as opposed to ascription configuration), the team coordinator defines filters which pass messages by applying selectors.
    
  Each top level PO tree has its own summit configuration file, named <tt>MSGTREE.extras.summit</tt>:   Each top level PO tree has its own summit configuration file, named <tt>MSGTREE.extras.summit</tt>:



Ilic: ascription-config file moved one level up, with implied adjustments.
2010-06-19T13:55:21Z
ascription-config file moved one level up, with implied adjustments.

				
				
				
				
			
			← Older revision
			Revision as of 13:55, 19 June 2010
			
Line 68:
Line 68:
  </code>   </code>
    
− The team coordinator already has this part of the repository tree locally due to regular summit operations. For the same reason Pology is already set up. Setting up the ascription system is now simple. The file <tt>ascription-config</tt> is created in the root of the summit: + The team coordinator already has this part of the repository tree locally due to regular summit operations. For the same reason Pology is already set up. Setting up the ascription system is now simple. The file <tt>ascription-config</tt> is created in the parent directory of the summit:
    
  <code text>   <code text>
  ...   ...
       LANG/        LANG/
  +         ascription-config
           summit/            summit/
               messages/                messages/
               docmessages/                docmessages/
−             ascription-config  
  </code>   </code>
    
Line 87:
Line 87:
  [global]   [global]
    
− # The root of the ascription catalog tree. + # Roots of the catalog and ascription trees.
− ascript-root = ../summit-ascript + catalog-root = summit
  + ascript-root = summit-ascript
    
  # The underlying version control system.   # The underlying version control system.
Line 122:
Line 123:
  Some notes:   Some notes:
    
− * The <tt>ascript-root</tt> setting should be exactly <tt>../summit-ascript</tt>, for the reason mentioned later. + * The <tt>ascript-root</tt> setting should be exactly <tt>summit-ascript</tt>, for the reason mentioned later.
    
  * <tt>commit-message</tt> field, if defined, allows team members to commit without providing a commit message. The value given by this field will be used by default, with translator's user name appended to the end in special syntax. For example: <tt>Translation updates. [>alice]</tt>. (Translator's user name is also appended to manually supplied commit messages.) Translators can still supply a commit message when they wish, as shown later. If this field is not set, the commit message is supplied as usual on committing.   * <tt>commit-message</tt> field, if defined, allows team members to commit without providing a commit message. The value given by this field will be used by default, with translator's user name appended to the end in special syntax. For example: <tt>Translation updates. [>alice]</tt>. (Translator's user name is also appended to manually supplied commit messages.) Translators can still supply a commit message when they wish, as shown later. If this field is not set, the commit message is supplied as usual on committing.
Line 185:
Line 186:
  ...   ...
       LANG/        LANG/
  +         ascription-config
           summit/            summit/
               messages/                messages/
Line 193:
Line 195:
                   ...                    ...
               docmessages/                docmessages/
−             ascription-config  
           summit-ascript/            summit-ascript/
               messages/                messages/
Line 469:
Line 470:
  === Shuffling Ascription Catalogs  ===   === Shuffling Ascription Catalogs  ===
    
− Sometimes summit catalogs are shuffled in the repository: moved to another module, renamed, one catalog split into two, two catalogs merged into one. Such shuffling should be exactly mirrored in the ascription tree, and this too is done on the repository side, at the same time. This relies on the ascription root being set exactly to <tt>../summit-ascript</tt> in the ascription configuration. So the team coordinator has nothing special to do here. + Sometimes summit catalogs are shuffled in the repository: moved to another module, renamed, one catalog split into two, two catalogs merged into one. Such shuffling should be exactly mirrored in the ascription tree, and this too is done on the repository side, at the same time. This relies on the ascription root being set exactly to <tt>summit-ascript</tt> in the ascription configuration. So the team coordinator has nothing special to do here.
    
  If instead in the central KDE repository the translation team is working in an external repository, by consequence the ascription system must be set up in that repository. But so long as <tt>process_orphans.sh</tt> script from <tt>trunk/l10n-support/scripts/</tt> is used to shuffle catalogs in the external repository as well, the ascription catalogs will be properly handled.   If instead in the central KDE repository the translation team is working in an external repository, by consequence the ascription system must be set up in that repository. But so long as <tt>process_orphans.sh</tt> script from <tt>trunk/l10n-support/scripts/</tt> is used to shuffle catalogs in the external repository as well, the ascription catalogs will be properly handled.



Ilic: Corrected note on -C option. Mentioned removal of previous fields.
2010-05-29T10:51:18Z
Corrected note on -C option. Mentioned removal of previous fields.

				
				
				
				
			
			← Older revision
			Revision as of 10:51, 29 May 2010
			
Line 149:
Line 149:
  </code>   </code>
    
− The argument <tt>commit</tt> is the ascription mode, and the <tt>-u</tt> option provides the user name to which ascriptions are made. This is an important point: ascriptions are made to a user defined in ascription configuration, and have nothing to do with VCS accounts; someone who has the account can commit in the name of someone who does not. It is the <tt>--all-reviewed</tt> option that declares all messages to be reviewed as well (note that it is normally used only this once, and not for normal day to day reviewing). The <tt>-C</tt> option prevent automatic committing by <tt>poascribe</tt>, which is useful for this initial step. Finally the paths which contain all summit catalogs are given. + The argument <tt>commit</tt> is the ascription mode, and the <tt>-u</tt> option provides the user name to which ascriptions are made. This is an important point: ascriptions are made to a user defined in ascription configuration, and have nothing to do with VCS accounts; someone who has the account can commit in the name of someone who does not. It is the <tt>--all-reviewed</tt> option that declares all messages to be reviewed as well (note that it is normally used only this once, and not for normal day to day reviewing). The <tt>-C</tt> option prevents automatic adding and committing to version control, which is useful for this initial step. Finally the paths which contain all summit catalogs are given.
    
  When the <tt>poascribe</tt> command is issued, a progress bar will appear, and the following output will start to unfold:   When the <tt>poascribe</tt> command is issued, a progress bar will appear, and the following output will start to unfold:
Line 204:
Line 204:
  </code>   </code>
    
− The ascription tree can now be committed as usual (<tt>poascribe</tt> will have already added it): + During the ascription some summit PO files may have been modified as well, in that any previous fields (<tt>#| ...</tt>) on translated messages have been removed. (These fields are sometimes erroneously left in by older PO editors.)
  +  
  + The newly created ascription tree (and any modifications to summit tree) can now be committed as usual:
    
  <code bash>   <code bash>
− $ svn commit LANG/summit-ascript/ -m "Initial ascription." + $ svn add LANG/summit-ascript
  + $ svn commit LANG/summit LANG/summit-ascript -m "Initial ascription."
  </code>   </code>

← Older revision		Revision as of 15:19, 19 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Localization/Workflows/PO_Summit}}~~	+

	{{LocalizationBrowser\|		{{LocalizationBrowser\|