Translate Toolkit & Pootle wordforge

wordforge:analysis_of_process_and_workflow

Wed, 04 Oct 2006 01:16:28 +0000

1159924227		current
Line 100:		Line 100:
	==== Workflows ====		==== Workflows ====

-	A workflow is simply a sequence of phases that translatable content will follow during its translation or localisation. Each phase is assigned a player and the rights that this player has in the work process.	+	A workflow is simply a sequence of phases that translatable content will follow during its translation or localisation. Each phase is assigned to a player, together with the rights that this player has in the work process.

	Workflows might be as simple as one single translation phase by a translator who has the right to approve, or quite complex, requiring several phases of review, some of them mechanical and other performed by human reviewers.		Workflows might be as simple as one single translation phase by a translator who has the right to approve, or quite complex, requiring several phases of review, some of them mechanical and other performed by human reviewers.

wordforge:debian

Sat, 02 Sep 2006 11:37:22 +0000

1157196954		current
Line 503:		Line 503:
	the po4a package maintainers: Nicolas François, Thomas Huriaux, Martin Quinson et al.		the po4a package maintainers: Nicolas François, Thomas Huriaux, Martin Quinson et al.

-	Note that Pootle [[nonpo\|integrates]] the po4a package.	+	Note that Pootle [[http://translate.sourceforge.net/wiki/nonpo\|integrates]] the po4a package.

	Michael Bramer commented:		Michael Bramer commented:

wordforge:design_philosophy

Wed, 01 Feb 2006 15:22:03 +0000

	current
Line 1:	Line 1:
	+	====== Design Philosophy ======
	+
	+	We could code everything but then of course we'd never be finished! So how do we prioritise items for coding and design?
	+
	+	* Implement the minimal that we need - TBX is great but lets code what we need now
	+	* Is their a user for this functionality - if not code that to test the validity of the implementation
	+	* Code to data - if you have data to exercise the featuer then code it. Considering of course the other points
	+	* Choose existing technologies - we don't want to reinvent the wheel
	+	* Don't fall in love with cool tech - the latest greatest protocol could be our downfall
	+
	+
	+
	+
	+
	+

wordforge:file_system

Thu, 09 Feb 2006 08:45:33 +0000

1139474326		current
Line 27:		Line 27:
	===== File system Structure =====		===== File system Structure =====

-	The files will be stored in several levels, considering that the software piece is the most important. The levels will be:	+	Transalatable files will be stored using the operating system's file system, considering that the software piece is the most important. The levels will be:

	- Piece of software		- Piece of software
Line 33:		Line 33:
	- Language		- Language

-	And, inside the language files we will find the tree structure of files that is normal for the localisation of that project. For example:	+	And, inside the language directories we will find the translatable files, which in many cases are not all in one single directory, but structured in subdirectories. For example, OpenOffice files are normally in one directory that has subfolders for each OpenOffice subproject...

	/		/
Line 50:		Line 50:
	\| /OpenOffice/2.0.2/km/basctl/source		\| /OpenOffice/2.0.2/km/basctl/source

-	But Pootle will have to allow user to look at the files from the point of view of a language-centred project, looking at a given language and seeing which projects are attached, and then which version. It will be transparent and this view will be given by Pootle using information stored in the Lucene DB.	+	But Pootle will have to allow user to look at the files from the point of view of a language-centred project, taht is, looking at a given language and seeing which projects are being translated to that language in this Pootle server, and then which version. It will be transparent and this view will be given by Pootle using information stored in the Lucene DB.

-	We also considered doing the file system with language at the top level, but if we use a database to present information in Pootle to the user, this does not really matter.	+	We also considered doing the file system with language at the top level, but if we use a Lucene to present information in Pootle to the user, this does not really matter.

-	* In version 0.9 only PO files will be stored in Pootle.	+	* In version 0.9 of Pootle only PO files will be stored in Pootle.
	* After version 0.9, only XLIFF files will be stored but they will be downloadable also in PO format, with Pootle doing the conversion from XLIFF to PO on the fly.		* After version 0.9, only XLIFF files will be stored but they will be downloadable also in PO format, with Pootle doing the conversion from XLIFF to PO on the fly.

Line 77:		Line 77:

	FIXME {DB I still prefer the Lucene way although I think we need to use fewer files or hidden files to track our change info. I don't like the DB idea as it means structure that have to be changed between versions its volatile it requires admin.}		FIXME {DB I still prefer the Lucene way although I think we need to use fewer files or hidden files to track our change info. I don't like the DB idea as it means structure that have to be changed between versions its volatile it requires admin.}
-
-

wordforge:functional

Sat, 05 Jan 2008 08:52:54 +0000

		current
Line 1:		Line 1:
		+	~~REDIRECT>developers:index~~

wordforge:functional_specificaions

Sun, 01 Oct 2006 12:29:48 +0000

1158347335		current
Line 181:		Line 181:
	==== About Process ====		==== About Process ====

-	The page on [[Analysis of Process and WorkFlow]] studies what phases a translation and localisation process can go through, analysing the possible players who might participate in the process, the phases that the process might go through, the rights that each player must have in order to participate in the process and finally, the creation of workflows for localisation composed of different phases.	+	The page on [[Analysis of Process and WorkFlow]] studies what phases a translation and localisation process can go through, analysing the possible players who might participate in the process, the rights that each player must have in order to participate in the process and, finally, the creation of workflows for localisation composed of different phases. The page on [[Process information on XLIFF files]] proposed a way of encoding the different phases inside this format, and the changes in the information about the translations that must take place when new phases take place.

	A file in Pootle will undergo several of the following processes:		A file in Pootle will undergo several of the following processes:

wordforge:index

Mon, 07 Apr 2008 13:13:49 +0000

1207574029		current
Line 7:		Line 7:
	WordForge took the [[toolkit:index\|Translate Toolkit]] and [[pootle:index\|Pootle]] to new heights. The project also enhanced these tools to become more compliant with the various LISA standards ([[toolkit:TMX]], [[toolkit:TBX]]). Pootle acts as a localisation management system in a localisation environment.		WordForge took the [[toolkit:index\|Translate Toolkit]] and [[pootle:index\|Pootle]] to new heights. The project also enhanced these tools to become more compliant with the various LISA standards ([[toolkit:TMX]], [[toolkit:TBX]]). Pootle acts as a localisation management system in a localisation environment.

-	The projects end objective was to make it easier for new teams to start localising and to use tools to help us improve the quality of localised software. To that end the project was a success and has helped to stimulate further development in the FOSS localisation space.	+	The project's end objective was to make it easier for new teams to start localising and to use tools to help us improve the quality of localised software. To that end the project was a success and has helped to stimulate further development in the FOSS localisation space.

wordforge:inline_checking_for_convertors

Wed, 26 Apr 2006 08:29:31 +0000

1145456249		current
Line 24:		Line 24:
	* 'discard-error' - only discard translation that fail an 'error' check		* 'discard-error' - only discard translation that fail an 'error' check
	* 'discard-all' - discard translations that fail an 'error' or a 'warning' check		* 'discard-all' - discard translations that fail an 'error' or a 'warning' check
-

	===== Overridding Checks =====		===== Overridding Checks =====
Line 37:		Line 36:
	To report a failed test. It is proposed that an entry of:		To report a failed test. It is proposed that an entry of:

-	# (pofilter) -variable	+	# (pofilter) -variables
		+
		+	Be use to indicate that the test should be ignored. The colon and description are optional, thus allowing a simple minus sign to be added to override the test. If you wanted to ignore a specific variable you could do:

-	Be use to indicate that the test should be ignored. The colon and description are optional, thus allowing a simple minus sign to be added to override the test	+	# (pofilter) -variables: blah

	===== Generic Behaviour =====		===== Generic Behaviour =====

wordforge:language_specific_comments

Thu, 01 Jun 2006 23:32:31 +0000

	current
Line 1:	Line 1:
	+	Farzaneh Sarafraz, from the OpenOffice Persian team comments in the OpenOffice localization list:

	+	Here is a summary of what goes wrong when trying to check the Persian
	+	translation using common filters.
	+
	+	* acronyms: We translate most of the acronyms into Persian, e.g. CD or
	+	URL. The test fails.
	+
	+	* brackets: It works well with paranthesis. When it comes to square
	+	brackets, it fails since in the right-to-left languages (including
	+	Persian) ] stands for opening brackets and comes before [.
	+
	+	* doublequoting & singlequoting: The characters used for them in Persian
	+	are « and ». So the test fails whenever the message contains quotation
	+	marks.
	+
	+	* escapes: causes problems when there is \" in the string because of the
	+	above problem.
	+
	+	* doublewords: The test should check for double words in the original
	+	message and should not alert when it contains double words as well.
	+	There are messages such as "Dot Dot Dash" among OO.o strings.
	+
	+	* endpunc, startpunc, purepunc & puncspacing: Persian doesn't use
	+	English punctuation marks. The test fails when we use ؟ for ? and ٪ for
	+	%. Comma and Semicolon changes to ، and ؛ in Persian (as well as other
	+	right-to-left scripts) so the test fails when the string contains any
	+	punctuation marks except the period.
	+	Another problem is that the translated string doesn't necessarily keep
	+	the word order. For example, there is a string "Automatic bold and
	+	_underline_". The word-by-word Persian translation would be "bold and
	+	_underline_ automatic". Both startpunc and endpunc are violated.
	+
	+	* numbers: Persian doesn't use European digits for numbers. The test is
	+	of no use with Persian digits (Extended Arabic-Indic digits).
	+
	+	* sentencecount: it misunderstands floating points with full stops.
	+	Persian uses a different character for decimal separator (U+066B). The
	+	dot abbreviations also cause problems in counting sentences.
	+
	+	* simplecaps & startcaps: Might not be useful even for Latin scripts,
	+	since the capitalization pattern could be different from English. Not
	+	good for other scripts.
	+
	+	Disabling all these filters is almost equal to not using pofilter at
	+	all. In fact msgfmt just checks the syntactical correctness of the file.
	+	It doesn't do anything more than what pofilter does; but the number of
	+	false positive results of poilter is what pushes our translators away.

wordforge:meeting

Thu, 01 Feb 2007 16:20:08 +0000

1170340344		current
Line 16:		Line 16:

	===== To bring =====		===== To bring =====
		+


Line 29:		Line 30:
	* Malaria stuff if needed		* Malaria stuff if needed
	* [[http://en.wikipedia.org/wiki/Image:BathingSuit1920s.jpg\|Swimming costume]]		* [[http://en.wikipedia.org/wiki/Image:BathingSuit1920s.jpg\|Swimming costume]]
-	* [[http://ads.easyinfo.co.za/htm/custom/stargazer/back/images/MARILYNM.jpg\|Light, summer clothes - it is hot and sometimes mildly humid]]	+	* [[http://ads.easyinfo.co.za/htm/custom/stargazer/back/images/MARILYNM.jpg\|Light, summer clothes]] - it is hot and sometimes mildly humid
	* [[http://en.wikipedia.org/wiki/Fly_swatter\|Fly swatter]]		* [[http://en.wikipedia.org/wiki/Fly_swatter\|Fly swatter]]

wordforge:mozilla_pootle_server_software_spec

Tue, 25 Jul 2006 15:10:26 +0000

1153840046		current
Line 32:		Line 32:
	==== Generate POT files ====		==== Generate POT files ====

-	make -f tools/l10n/l10n.mk create-en-US	+	make -f tools/l10n/l10n.mk create-en-US
-	moz2po -P l10n/en-US pot	+	moz2po -P l10n/en-US pot

	==== PO Generation ====		==== PO Generation ====

wordforge:off-line_translation_editor_specifications

Fri, 14 Jul 2006 02:19:36 +0000

1145604789		current
Line 98:		Line 98:
	==== Permitting preview of some translated documents for certain formats ====		==== Permitting preview of some translated documents for certain formats ====

		+
		+	===== String managment =====
		+
		+	It is necessary to be able to perform easily some functions that affect several string, such as replacing a term by a another one in an application. This cannot be done automatically in many cases. An adequate tool for computer-asssited change must be included.

	===== Concepts in the Editor =====		===== Concepts in the Editor =====

wordforge:ooo_xliff

Wed, 13 Dec 2006 13:53:43 +0000

1164979864		current
Line 24:		Line 24:

	* <del>Make pogrep work with multiple filetypes</del> - AP		* <del>Make pogrep work with multiple filetypes</del> - AP
-	* <del>Make pofilter work with multiple filetypes</del> - AP FIXME doesn't place (pofilter) comments correctly in XLIFF	+	* <del>Make pofilter work with multiple filetypes</del> - AP <del>FIXME doesn't place (pofilter) comments correctly in XLIFF</del>
	* Perhaps specifying states and state qualifiers: http://www.oasis-open.org/committees/xliff/documents/xliff-specification.htm#state		* Perhaps specifying states and state qualifiers: http://www.oasis-open.org/committees/xliff/documents/xliff-specification.htm#state
	* Decide where the message goes		* Decide where the message goes
Line 32:		Line 32:
	* pot2po with current functionality to update an existing po file to new POT file		* pot2po with current functionality to update an existing po file to new POT file
	* restore the old TM functionality by calling the methods of the new TM tool.		* restore the old TM functionality by calling the methods of the new TM tool.
-	* Make pomerge work with multiple filetypes (already does, but rewrite factory part to use storage.factory) (very short)	+	* <del>Make pomerge work with multiple filetypes (already does, but rewrite factory part to use storage.factory) (very short)</del> Wasn't so very short... -- Andreas
	* oo2xliff - AP?		* oo2xliff - AP?
	* Decide on the default filestyle (consider using multiple file-tags, although our support for them is not great)		* Decide on the default filestyle (consider using multiple file-tags, although our support for them is not great)

wordforge:permissions

Wed, 12 Jul 2006 12:39:30 +0000

1152707720		current
Line 10:		Line 10:
	* identified users can only suggest translations, and apply for team membership		* identified users can only suggest translations, and apply for team membership
	* team members can translate strings		* team members can translate strings
-	* by default, a language supervisor is superviser for all projects in the relevant language without an explicitely assigned superviser	+	* by default, a language supervisor is supervisor for all projects in the relevant language without an explicitely assigned supervisor
-	* in the projects for which they are superviser, language supervisors can	+	* in the projects for which they are supervisor, language supervisors can
	* assign the "team member" role to identified users		* assign the "team member" role to identified users
	* set goals		* set goals
Line 45:		Line 45:

	==== Variation 1D ====		==== Variation 1D ====
-	Assume the same setup as variation 1B. Chinese volunteers want to join, but the site administrator doesn't want to be concerned with the administration of the extra language. User X registers, and the site administrator appoints X as language superviser for Chinese. As other Chinese translators register, X assign team rights to the new translators. Because the site wide permissions are that team members can translate, X don't need to change any permissions to allow the Chinese team members to translate.	+	Assume the same setup as variation 1B. Chinese volunteers want to join, but the site administrator doesn't want to be concerned with the administration of the extra language. User X registers, and the site administrator appoints X as language supervisor for Chinese. As other Chinese translators register, X assign team rights to the new translators. Because the site wide permissions are that team members can translate, X don't need to change any permissions to allow the Chinese team members to translate.

wordforge:po_handling

Mon, 06 Feb 2006 09:54:58 +0000

	current
Line 1:	Line 1:
	+	====== How to handle PO files ======

	+	Pootle currently talks directly to PO files in the future we are adding XLIFF support and this is how we could handle PO with XLIFF.
	+
	+	===== Everything is XLIFF =====
	+
	+	* Store Pootle files in XLIFF using the <skel> to store the original PO
	+	* All process info is then carried in the XLIFF
	+	* Downloads of PO files are then extracted from the XLIFF
	+
	+	* PROs
	+	* One format
	+	* CONs
	+	* Not as simple to get PO files out
	+	* xliff2po must work flawlessly
	+
	+	===== PO and XLIFF simultatiously =====
	+
	+	* Pootle can handle either PO files or XLIFF
	+	* XLIFF stores process info internally
	+	* Pootle stores snippets of process info in parrallel files eg .file.po.xlf
	+
	+	* PROS
	+	* Easy to understand
	+	* CONS
	+	* Multiple formats - cumbersome

wordforge:priority_issues

Wed, 26 Apr 2006 06:08:01 +0000

1145879143		current
Line 3:		Line 3:
	These are urgent items that need attention		These are urgent items that need attention

-	- PyLucene and performance	+	^ Issue ^ Priority ^ Resp. ^ Description ^
-	- Pootle server	+	\| PyLucene and performance \| High \| DF \| We're being hit at startup because of PyLucene, benchmark and look at alternatives \|
-		+	\| Pootle server \| High \| AE, DB \| Live server needed \|
		+	\| Pootle as CGI using mod_python \| Medium \| DF \| We need to be able to run Pootle on sourceforge ie without an additional HTTP server \|

wordforge:process_information

Sat, 22 Apr 2006 05:37:58 +0000

1145650185		current
Line 86:		Line 86:
	During the creation of this phase, it is also interesting to count messages and include the count information in the file.		During the creation of this phase, it is also interesting to count messages and include the count information in the file.

-	FIXME {Javier: Define which counters and how they are coded}	+	FIXME {Javier: Define which counters and how they are coded. All counters can be included and initialised to 0, or we can consider that counters that do not exist are 0, but this might be too much to assume sometimes}

	== File import into Pootle phase ?? ==		== File import into Pootle phase ?? ==
Line 94:		Line 94:
	* I see no reason to include this information or to have a phase for this		* I see no reason to include this information or to have a phase for this

-	== Instantiation and initialisation ==	+	== Instantiation and initialisation (Upgrade from an old version) ==

	* Date in which the file was initialised for this language		* Date in which the file was initialised for this language
	* Version of the file (project name) from which info was taken to initialise		* Version of the file (project name) from which info was taken to initialise
-	* Information about phases in the file form which info was taken	+	* Information about phases in the file from which info was taken
		+	* Name and version of the tool that was used to do the upgrade
		+	* This whole set of information does not influence the process, but it is interesting to know when the origin of the information needs to be tracked. The existence of the phase itself shows that a step was taken, and that the old project was probably eliminated form Pootle.

		+	All the upgrade, translation, review and approval phases of the old project are copied right after the Creation phase of this file, then we add our own phase. Glossary and TM inclusion phases are not kept, as this information will not be copied from the file when upgrading. Then, a new Upgrade phase is added.

	<phase		<phase
Line 106:		Line 109:
	date = "2006-01-25T21:06:00Z"		date = "2006-01-25T21:06:00Z"
	x-prior-project="OpenOffice 2.0.2"		x-prior-project="OpenOffice 2.0.2"
		+	tool="Translate Toolkit pot2po 0.9"
	</phase>		</phase>
		+
		+	FIXME {Javier update counter information, adding counts of translated and fuzzy messages, as well as reviewed and approved messages. It might well be that the file was not yet reviewed or approved when the Upgrade took place}

	== Inclusion of Glossary info in XLIFF phase ==		== Inclusion of Glossary info in XLIFF phase ==

wordforge:process_information_on_xliff_files

Sun, 01 Oct 2006 12:33:20 +0000

	current
Line 1:	Line 1:
	+
	+	====== Process information in XLIFF files ======
	+
	+	XLIFF is a standard file format specifically developed by the OASIS consortium to store translation and localisation information. Among many other bits of information, the XLIFF format permits storing information about the phases that the file has gone through. These phases are stored at the beginning of the file (in the <header>), and could be maintained throughout the whole life of the file.
	+
	+	Information stored in an XLIFF file might refer to the whole file (and in this case it will be placed in the <header> of the file) or to one of the translations, in which case it will be included inside the corresponding <trans-unit>.
	+
	+	===== Structure inside the XLIFF file (what the standard says) =====
	+
	+	The XLIFF specifications permit the definition of a <phase-group> element inside the <header>. This element might contain as many <phases> as needed. In particular, the specifications say the following:
	+
	+	The information must be placed in the a <phase-group> element inside the <header>. Inside the <phase-group> each bit of information must be include in a <phase> element.
	+
	+	The <phase> contains metadata about the tasks performed in a particular process. The optional phase-name attribute uniquely identifies the phase for reference within the file. The required process-name attribute identifies the kind of process the phase corresponds to; e.g. "proofreading". The optional company-name attribute identifies the company performing the task. The optional tool-id attribute references the <tool> used in performing the task. The optional date attribute provides a timestamp indicating when the task was performed. The optional job-id attribute allows an ID to be assigned to the job. The optional contact-name, contact-email, and contact-phone attributes all refer to the person performing the task.
	+
	+	Required attributes:
	+
	+	phase-name, process-name. [ERRATA: phase-name is considered optional in the text above, but mandatory here]
	+
	+	Optional attributes:
	+
	+	company-name, tool, tool-id, date, job-id, contact-name, contact-email, contact-phone.
	+
	+	Contents:
	+
	+	Zero, one or more <note> elements.
	+
	+	Structure:
	+
	+	<xliff>1
	+	\|
	+	+- <file>+
	+	\|
	+	+--- <header>?
	+	\| \|
	+	\| +--- <skl>?
	+	\| \| \|
	+	\| \| +--- (<internal-file> \| <external-file>)1
	+	\| \|
	+	\| +--- <phase-group>?
	+	\| \| \|
	+	\| \| +--- <phase>+
	+	\| \| \|
	+	\| \| +--- <note>*
	+
	+	(legend: 1 = one
	+	+ = one or more
	+	? = zero or one
	+	* = zero, one or more)
	+
	+	The standard does not specify in which order the phases must be stored in the phase group. For performance purposes, it would be most interesting to ensure that the phases are in chronological order. Inverse chronological order (current phase is first in the list) would improve performance even further.
	+
	+	===== Information and phases that we have and might consider including =====
	+
	+	==== Template XLIFF file creation ====
	+
	+	This action is not a proper phase, and it is not necessary to create a <phase> element for this action, as most of the necessary information can be coded in the <file> element.
	+
	+	The <file> element includes a date attribute that is defined as "the creation date of this XLIFF file". It is unclear if this date refers to the date in which the template was created or the date in which this specific instance of the file was created. XLIFF files are created as empty templates, which are later translated or filled with prior translations, or the result of merging two files. In either case, the important date is the date in which the data was extracted from the original data in the source language. Intermediary processes should attempt to keep this data, so that it can be fed into the XLIFF file. A possible extension of the XLIFF standard would be to have a separate date in which the present instance of the file (specifically for one language) was created.
	+
	+	The file creation date (and maybe tools) is useful to ensure that upgrades are always done from older files (older versions of the original software) to newer ones.
	+
	+	The <file> element also has other attributes that permit defining the piece of software and the exact version that the XLIFF file belongs to, ensuring that different versions of the project are not confused by the translator.
	+
	+	It would be very interesting to have a new attribute that indicates the path of this specific file inside the Project tree (in case the project has several files stored in several directories. This information helps translation management tools know exactly where the file belongs.
	+
	+	The <file> element does have one attribute to indicate which <tool> was used to create the XLIFF file.
	+
	+	When the file is created, it is also interesting to count messages and include the count information in the file (in the <count-group>).
	+
	+	If the file is created from a PO file, the standard mandates that the header of the PO file be stored as the first translation unit, with an empty <source> string and the contents of the complete PO header as the <target> string.
	+
	+	==== Instantiation and initialisation (upgrade from an old version) ====
	+
	+	An XLIFF file that is ready for localisation is either:
	+
	+	* A new XLIFF file for which the target language is defined, or:
	+	* An XLIFF file in which the already-translated contents of older versions of the same file (or of translation memory) for a specific language has been integrated.
	+
	+	In the second case, if the file is the update of an older version of the same file, there is information that must be kept. In principle, all the phases of the old file should be integrated in the updated version, so that information is maintained.
	+
	+	The one piece of information that is new is the version of the file from which the content was taken (prior to the one of the present file). This information might be useful for knowing what the history of the information in a file is, and specifically from where the content was brought in. Nevertheless, if a phase is kept for each upgrade (which for some projects might take place two or three times a week), then the number of phases generated might be too large. The alternatives to including this repetitive phase are either adding this information somewhere else in the <header> of the file or storing information only when the last phase of the file is not an upgrade phase.
	+
	+	If such phase is used, it should include:
	+
	+	* Date of upgrade.
	+	* Version of the file (project name) from which info was taken to initialise
	+	* Name and version of the tool that was used to do the upgrade
	+
	+	Again, this whole set of information does not influence the process, but it is interesting to know when the origin of the information needs to be tracked. The existence of the phase itself shows that a step was taken, and that the old project was probably eliminated form the system.
	+
	+	All the upgrade, translation, review and approval phases of the old project are copied into this file, then this phase is added. Glossary and TM inclusion phases are not kept, as this information will not be copied from the file when upgrading.
	+
	+	The upgrade phase will look like this:
	+
	+	<phase
	+	phase-name="xxx999"
	+	process-name="upgrade"
	+	date = "2006-01-25T21:06:00Z"
	+	x-prior-project="OpenOffice 2.0.2"
	+	tool="Translate Toolkit pot2po 0.9"
	+	</phase>
	+
	+	==== Inclusion of Glossary info in XLIFF phase ====
	+
	+	The XLIFF file format allows the inclusion of a glossary inside its structures. The glossary is included in the <header> of the file, and can be either an embedded glossary inside the file or a reference to and external glossary.
	+
	+	Including a glossary phase has one major interest: keeping track of the date in which the glossary was embedded. When the process of embedding is an asynchronous process that might be repeated if there is an update of the glossary, it is important to keep track of either the version of the glossary or its last date of modification. This will indicate if the process must be repeated or not.
	+
	+	If the last phase available is the inclusion or update of a glossary, and a new revision is necessary, then the prior phase will be erased, and a new one annotated after the revision of the glossary information in the file. It does not make sense to maintain information about how many times the glossary was updated between other processes, as only the last upgrade is important (and not to other processes).
	+
	+	The phase will look like
	+
	+	<phase
	+	phase-name="xxx213"
	+	process-name="glossary inclusion"
	+	date = "2006-01-25T21:06:00Z"
	+	</phase>
	+
	+	==== Inclusion of Translation Memory (TM) information in an XLIFF phase ====
	+
	+	Unlike in the case of glossaries, TM is not included in the <header> of the file, but inside each specific translation unit (<trans-unit>). Translation memory information can be placed inside the <target> element of the translation unit, if it is a perfect match, or as an alternative translation unit <alt-trans>.
	+
	+	As the <header> is concerned, we are in a similar case as with glossaries. We indicate in a phase the last time in which TM was analysed to include information in the file. We only upgrade TM content in the file is the date of the TM is posterior to the time stamp in a prior TM phase.
	+
	+	The phase will look like:
	+
	+	<phase
	+	phase-name="xxx213"
	+	process-name="TM inclusion"
	+	date = "2006-01-25T21:06:00Z"
	+	</phase>
	+
	+	For each match that is considered of interest for the translator, but not an exact match the TM inclusion process should create an <alt-trans> unit with as much info as is available in TM, plus the information generated by the TM analysis engine (for example quality of match).
	+
	+	<alt-trans xml:lang="fr" match-quality="92">
	+	<source xml:lang="en-US">Knights of the round table, taste how good the wine is</source>
	+	<target xml:lang="fr" state="needs-review-l10n" phase-name="xxx321">
	+	Chevaliers de la table ronde, goutez mois si le vin est bon. </target>
	+	<context-group>
	+	<context context-type="x-openoffice">
	+	avmedia/source/framework.po-mediacontrol.src#AVMEDIA_STR_ENDLESS.string.text
	+	</context>
	+	</context-group>
	+	</alt-trans>
	+
	+	Note that the <target> of the <alt-trans> element makes reference to the phase in which it was included in the file.
	+
	+	What an exact match is would have to be defined, and there could even be grades of exact matches. An exact ID match, in which it is clear that the string belongs to the same string of the same file of the same program, could go directly into the <target>, not marking the string as fuzzy, nor for review. An exact match or unknown origin or from another application would be marked as a fuzzy match, by setting the state attribute of the <target> element to: "needs-review-translation".
	+
	+	In the case of an exact match, the phase-name attribute of the <target> element of the <trans-unit> will make reference to the TM <phase> in which the content was filled.
	+
	+	In this phase we may also include the translation of the source messages to a third language that is not that of the source nor of the target of this file. This information is given to help the translator, who might be more proficient in an intermediate language (for example Spanish when translating to South or Central American indigenous languages) than in English. These translations would also be included in <alt-trans> units that would make reference to the phase-name,
	+
	+	==== Translation phase ====
	+
	+	Normal translation phase. The translator receives a file in which some or all the messages need translation, and performs the translation. The file might have glossary and Translation Memory data. A translation phase last all the period in which a translator is working on a file, the phase will only terminate when somebody else (such as a reviewer) starts working on the file. The start date of the phase is included in the phase, the termination date is the start date of the next phase.
	+
	+	The phase will look like:
	+
	+	<phase
	+	phase-name="xxx234"
	+	process-name="translation"
	+	date = "2006-01-25T21:06:00Z"
	+	contact-name="Alberto Martinez"
	+	contact-email="alberto@martinez.com">
	+	</phase>
	+
	+	Each time the translator creates or modifies a <target> element, the <target> must be associated to the current phase through the phase-name attribute and the status must be changed depending on the rights of the translator (and the workflow that he is following). If the workflow requires a review phase after translation, the status will need to be changed to "needs-review-translation" (because it has been translated, but not yet reviewed).
	+
	+	==== Automatic review phase ====
	+
	+	In this phase the file goes through a number of automatic tests that may check conditions as different as alignment to glossary, capitalisation, spaces extra or missing at the beginning or end of the translation or correct tags inside the <target>.
	+
	+	The results of tests that are positive are stored in the state-qualifier attribute of the <target>. As much further detail in reasons for rejection is possible to detect by tests than the pre-defined possibilities offered by the standard as values for the state-qualifier attribute, it would be interesting to have a non-standard attribute that may be present when the value of the state-qualifier is "rejected-inaccurate". This way, editors that are not prepared for the extension may still see the general definition of rejection because of lack of accuracy. Nevertheless, an extension of the standard should be considered to add more standard values to this attribute.
	+
	+	In many cases it will still be important to give specific information why the string is rejected (such as specifying where in the string is the problem, which variable is missing from the target, what error in XML, etc. This information can be included in a note of the <trans-unit>
	+
	+	<phase
	+	phase-name="xxx"
	+	process-name="automatic review"
	+	date = "2006-01-25T21:06:00Z"
	+	tool ="Translate Toolkit pocheck 1.0">
	+	</phase>
	+
	+	The problem with associating translation to this phase is that we automatically loose the reference to the corresponding translation phase, as only one phase can be indicated for a translation unit. We will know when the information was checked, but no longer who translated it. We can assume that it is the translator in the prior translation phase, but this might not always be correct.
	+
	+	==== Manual authoritative review phase ====
	+
	+	As in the case of translation, a review phase will last all the period that a given translator spends working on a file. He will need to review message from all prior translation phases since the last review was performed.
	+
	+	The <phase> element should contain:
	+
	+	<phase
	+	phase-name="xxx"
	+	process-name="authoritative-proofreading"
	+	date = "2006-01-25T21:06:00Z"
	+	contact-name="Alberto Martinez's reviewer"
	+	contact-email="boss@martinez.com">
	+	</phase>
	+
	+	With each <target>, the reviewer might accept the string, correct it or reject it.
	+
	+	Each time the reviewer reviews or modifies a <target> and considers it correct, the <target> must be associated to the current phase through the phase-name attribute and the status must be changed to "translated". If the state-qualifier is fuzzy-match, the reviewer can fix it or leave it as it is, as if it was a non-translated message.
	+
	+	Again, the problem here is that we loose information. If there are two translations phases, followed by a review phase, we will know know in which of the two translation phases the translation took place.
	+
	+	<target
	+	phase-name="xxx321"
	+	status="translated"....
	+
	+	The reviewer might reject a translation, without fixing it. In this case, the state state-qualifier will be set to: rejected-* and the state to needs-translation. If needed a qualifying note can also be added.
	+
	+	<note
	+	xml:lang="af"
	+	from="reviewer"
	+	annotates="target">
	+	"File" is a noun in this context not a verb
	+	</note>
	+
	+	The reviewer might also accept non-aligned glossary, in that case it is necessary to change the state-qualifier, but it might be interesting to maintain the additional attribute that indicates lack of alignment to the present glossary, so that the glossary manager might add the new term to the glossary (or reject it). He might also accept other tests that have failed, if (s)he considers that the translation is correct.
	+
	+	The result of an authoritative review phase can either be a file that is considered correct by the reviewer or too incorrect to be corrected by him. In the second case, the file would be send back to the translator for a "review editing phase".
	+
	+	In this case, the standard does not seem to have a global attribute to specify that a file has not been approved by the reviewer and should be sent back to the translator. Only looking at non-approved items will the system know that the next step is either continuing with the workflow or returning the file to the translator.
	+
	+
	+	==== Manual non-authoritative review phase ====
	+
	+	This phase is similar to the prior one, except that the reviewer is not allowed to change the <target> translated by the translator, only to qualify it and to accept or not the automatic tests results. The file in most cases will be sent back to the translator, as the reviewer does not have the power to move it forward, (s)he is only advising the translator.
	+
	+	==== Review Editing phase ====
	+
	+	In the workflows in which the reviewer(s) is non-authoritative, there should also be an editing phase, normally performed by the original translator. The translator receives back a file that has been annotated by the automatic review process and/or a non-authoritative reviewer. The translator in this phase pays attention to the strings that have comments, and produces a file for the approver.
	+
	+	<phase
	+	phase-name="xxx238"
	+	process-name="review-edit"
	+	date = "2006-01-25T21:06:00Z"
	+	contact-name="Alberto Martinez"
	+	contact-email="alberto@martinez.com">
	+	</phase>
	+
	+
	+	==== Approval phase ====
	+
	+	In theory, the file that arrives for approval does not have any outstanding problems, and automatic test failures have been overridden by either translator or reviewer (whomever had the power to do it).
	+
	+
	+	<phase
	+	phase-name="xxx999"
	+	process-name="approval"
	+	date = "2006-01-25T21:06:00Z"
	+	contact-name="Big Boss"
	+	contact-email="bigboss@martinez.com">
	+	</phase>
	+
	+	The approver can accept or reject translations. When accepted the state is changed to final. The approval attribute of the <trans-unit> is changed to "yes". The <phase-name> of the translations made during this cycle (which had not been approved in a prior approval phase) will be changed to point to this approval phase.
	+
	+	If rejected they can use the same reasons and process used by the reviewer.
	+
	+	===== Uniqueness of phase names =====
	+
	+	All <phase-name>s in a file must be unique. It is important to ensure this, considering the case in which an upgrade brings in phases from another file. It is important to ensure uniqueness of the phase name of the Creation phase, so that it will not agree with other phase names. Many be phase name should be the name of the phase followed by a number. This way the phase names will always be manageable.
	+
	+

wordforge:requests

Tue, 28 Mar 2006 14:26:20 +0000

1143550688		current
Line 6:		Line 6:
	====== IDE ======		====== IDE ======
	Add the possibility to display in Pootle IDE comments contained in PO files, so that translators can understand the contest and also, maybe, leave messages to others, to explain why they made certain choices.		Add the possibility to display in Pootle IDE comments contained in PO files, so that translators can understand the contest and also, maybe, leave messages to others, to explain why they made certain choices.
		+
		+	Provide a way to define maximum length of a string, it means that a translator has a limit to input. This would be useful for certain projects (for example firmware), where only a fixed width string can be displayed.

wordforge:roadmap

Tue, 04 Jul 2006 08:44:45 +0000

1150828428		current
Line 72:		Line 72:

	* Toolkit 1.0		* Toolkit 1.0
-	* Migrate all filters to base.py.	+	* <del>Migrate all filters to base.py. </del> (Migrated: HTML, DTD, .properties and PO; Not migated: OpenOffice.org, Qt TS)
	* <del>po2xliff works according to spec</del>		* <del>po2xliff works according to spec</del>
	* <del>Can merge new PO changes to XLIFF</del>		* <del>Can merge new PO changes to XLIFF</del>
-	* Can merge XLIFF into XLIFF	+	* <del>Can merge XLIFF into XLIFF</del> (complex states will need some work)
	* <del>Can produce minimally changed PO files from any format ie PO->XXXX->PO should not produce any formatting changes.</del>		* <del>Can produce minimally changed PO files from any format ie PO->XXXX->PO should not produce any formatting changes.</del>

Line 84:		Line 84:
	* Uploads back PO or XLIFF interchangably, modifying the master XLIFF files.		* Uploads back PO or XLIFF interchangably, modifying the master XLIFF files.
	* Version Control		* Version Control
-	* Can work with files stored in CVS/SVN	+	* <del>Can work with files stored in CVS/SVN</del>
-	* Have a method to commit changes back to CVS/SVN (within Pootle or without)	+	* <del>Have a method to commit changes back to CVS/SVN</del> (within Pootle currently no simple tool to do commits outside Pootle except the mormal command line)
	* <del>Emulate KDE style drilldown</del>		* <del>Emulate KDE style drilldown</del>
	* Can filter to view only files that need attention		* Can filter to view only files that need attention

wordforge:roadmap_done

Tue, 02 May 2006 07:22:15 +0000

1146554320		current
Line 1:		Line 1:
-	===== Done =====	+	====== Roadmap: Completed Milestones ======

-	==== Translate Toolkit 0.8 ====	+	Once milestone work is complete it moves from the [[roadmap]] to here.
		+
		+	===== Translate Toolkit 0.8 =====

	Released 2006-02-21		Released 2006-02-21

wordforge:roles

Wed, 12 Jul 2006 12:39:08 +0000

1152707443		current
Line 4:		Line 4:
	* anonymous - A user who is not logged in		* anonymous - A user who is not logged in
	* registered - A user who is logged in, but not formally part of the language team. A newly registered user will automatically be in this class for all languages/projects.		* registered - A user who is logged in, but not formally part of the language team. A newly registered user will automatically be in this class for all languages/projects.
-	* team member - A user who is logged in, and who is accepted as part of the language team(s). This role is only active for the language where the identified user is accepted. In all other languages, the user has the "identified" role.	+	* team member - A user who is logged in, and who is accepted as part of the language team(s). This role is only active for the language where the identified user is accepted. In all other languages, the user has the "registered" role.
-	* language superviser** - One or more teammembers who have been appointed as supervisers across specific (or all) projects within one language. A user can be superviser for more than one language. In other languages, this user has the "identified**" role. If a superviser has been appointed for a specific project in a language, the other supervisers do not have superviser rights for that projects anymore, but "team member" rights.	+	* language supervisor** - One or more team members who have been appointed as supervisers across specific (or all) projects within one language. A user can be superviser for more than one language. In other languages, this user has the "registered" or "team member**" role. If a superviser has been appointed for a specific project in a language, the other supervisers do not have superviser rights for that projects anymore, but "team member" rights.
-	* project liason - One or more logged in users that liase with the upstream project. Probably has update and commit rights for the specific project(s). In other projects, this user has the "identified" role.	+	* project liason - One or more logged in users that liase with the upstream project. Probably has update and commit rights for the specific project(s). In other projects, this user has the "registered" role.
-	* site administrator - One or more superusers of a Pootle installation. Will appoint the project liasons and at least the first language supervisors	+	* site administrator - One or more superusers of a Pootle installation. Will appoint the project liasons and at least the first language supervisor for a given language.

	For a description of permissions, see [[permissions]].		For a description of permissions, see [[permissions]].

wordforge:sidebar

Wed, 02 Apr 2008 11:51:47 +0000

1207137048		current
Line 4:		Line 4:
	* [[http://www.opensocietyinstitute.com/\|Open Society Institute]].		* [[http://www.opensocietyinstitute.com/\|Open Society Institute]].
	* [[http://www.idrc.ca/\|IDRC]]		* [[http://www.idrc.ca/\|IDRC]]
		+
	----		----

wordforge:spec_pootle_statistics

Fri, 05 May 2006 12:01:07 +0000

	current
Line 1:	Line 1:
	+	====== Spec: Pootle Statistics ======
	+
	+	Create statistics that are usefull for translators
	+
	+	===== Goals =====
	+
	+	* Emulate the stats that already exist
	+	* Add more and better stats
	+	* Enable it all through templates
	+
	+	===== What we need to emulate =====
	+
	+	==== KDE Stats Pages ====
	+
	+	* Translate
	+	* Translate Percent
	+	* Fuzzy
	+	* Fuzzy Percent
	+	* Untranslated
	+	* Untranslated Percent
	+
	+	* Language
	+	* Module
	+
	+	* File
	+	* Location of file in SVN
	+
	+	==== Rosetta ====
	+
	+	They have done some nice things to their stats pages
	+
	+	* JavaScript table sorter
	+
	+	===== Extra Stuff =====
	+
	+	We want more
	+
	+	==== Toolkit related ====
	+
	+	* Failing check counts, per check and total. Also critical check failure counts
	+
	+	==== Values ====
	+
	+	* Rate of change. Need to track on a daily basis
	+	* Last translator
	+	* Last translated

wordforge:spec_statistics_filtering

Tue, 06 Jun 2006 07:06:39 +0000

	current
Line 1:	Line 1:
	+	====== Spec: Filtering on Statistics ======
	+
	+	We want the ability to focus the statistics pages ie see what needs to be done.
	+
	+	===== Goal =====
	+
	+	* A simple method of filtering
	+	* See only the work that needs attention
	+	* Options that are enough to be creative but not to confuse
	+

wordforge:specs

Wed, 12 Jul 2006 11:02:57 +0000

1146817002		current
Line 184:		Line 184:
	* Visual representation of progress (compare [[http://l10n.kde.org/scripts/l10n-stats/documentation.php\|KDE stats system]])		* Visual representation of progress (compare [[http://l10n.kde.org/scripts/l10n-stats/documentation.php\|KDE stats system]])
	* Balanced resource balanced statistics for projects, people and teams		* Balanced resource balanced statistics for projects, people and teams
		+
		+	====== Pootle Roles ======
		+	* Which [[roles]] exist
		+	* Different usage scenarios and [[permissions]]

wordforge:upload_and_download_merging_policy

Sat, 14 Jun 2008 11:39:10 +0000

1157121797		current
Line 3:		Line 3:
	When someone uploads a new file into Pootle we need to know what we do with the new string in the uploaded file.		When someone uploads a new file into Pootle we need to know what we do with the new string in the uploaded file.

-	(This page is based on requirements for pootle. For more on implementation, see [[friedel:merge]].)	+	(This page is based on requirements for pootle. For more on implementation, see [[developers:developers:friedel::merge]].)

	===== Current =====		===== Current =====

wordforge:version_control

Thu, 18 Jan 2007 10:08:05 +0000

1163754449		current
Line 96:		Line 96:
	* We could transport all PO files in XLIFF. Only works for people with XLIFF editors though. That way the messages are stored in XLIFF but the associated PO is in the skeleton (or the XLIFF could contain the XLIFF representation of the PO file per the spec...)		* We could transport all PO files in XLIFF. Only works for people with XLIFF editors though. That way the messages are stored in XLIFF but the associated PO is in the skeleton (or the XLIFF could contain the XLIFF representation of the PO file per the spec...)
	* For people with PO editors, we could still provide the file as PO, and just incorporate changes to the XLIFF file when it is returned		* For people with PO editors, we could still provide the file as PO, and just incorporate changes to the XLIFF file when it is returned
		+
		+	===== Technology =====
		+	Currently we call the command line programs, but there are alternatives:
		+
		+	==== CVS ====
		+
		+	There are two modules call PyCVS - http://software.cnx.rice.edu/downloads/python/pycvs/ which is a wrapper to the CVS commandline, and http://pycvs.sourceforge.net/ which is an implementation of the CVS protocol. There is also an implementation like this in the Python Demo directory.
		+
		+	==== SVN ====
		+	http://pysvn.tigris.org
		+

1152707443		current
Line 4:		Line 4:
	* anonymous - A user who is not logged in		* anonymous - A user who is not logged in
	* registered - A user who is logged in, but not formally part of the language team. A newly registered user will automatically be in this class for all languages/projects.		* registered - A user who is logged in, but not formally part of the language team. A newly registered user will automatically be in this class for all languages/projects.
-	* team member - A user who is logged in, and who is accepted as part of the language team(s). This role is only active for the language where the identified user is accepted. In all other languages, the user has the "identified" role.	+	* team member - A user who is logged in, and who is accepted as part of the language team(s). This role is only active for the language where the identified user is accepted. In all other languages, the user has the "registered" role.
-	* language superviser** - One or more teammembers who have been appointed as supervisers across specific (or all) projects within one language. A user can be superviser for more than one language. In other languages, this user has the "identified**" role. If a superviser has been appointed for a specific project in a language, the other supervisers do not have superviser rights for that projects anymore, but "team member" rights.	+	* language supervisor** - One or more team members who have been appointed as supervisers across specific (or all) projects within one language. A user can be superviser for more than one language. In other languages, this user has the "registered" or "team member**" role. If a superviser has been appointed for a specific project in a language, the other supervisers do not have superviser rights for that projects anymore, but "team member" rights.
-	* project liason - One or more logged in users that liase with the upstream project. Probably has update and commit rights for the specific project(s). In other projects, this user has the "identified" role.	+	* project liason - One or more logged in users that liase with the upstream project. Probably has update and commit rights for the specific project(s). In other projects, this user has the "registered" role.
-	* site administrator - One or more superusers of a Pootle installation. Will appoint the project liasons and at least the first language supervisors	+	* site administrator - One or more superusers of a Pootle installation. Will appoint the project liasons and at least the first language supervisor for a given language.

	For a description of permissions, see [[permissions]].		For a description of permissions, see [[permissions]].