Translate Toolkit & Pootle developers

developers:announcements

Mon, 15 Jun 2009 15:22:09 +0000

1245079118		current
Line 1:		Line 1:
-	= Announcements Use Cases =	+	==== Announcements Use Cases ====

-	* Tell everyone that there is a new project.	+	* Tell everyone that there is a new project.
-	* Tell everyone in a given project about some event e.g. deadline, new files, etc.	+	* Tell everyone in a given project about some event e.g. deadline, new files, etc.
-	* Tell everyone in a given language about some event.	+	* Tell everyone in a given language about some event.
-	* Tell everyone in a given language in a given project	+	* Tell everyone in a given language in a given project
-	* Anyone interested in a project (added it to their profile) can send a message to all interested in the project.	+	* Anyone interested in a project (added it to their profile) can send a message to all interested in the project.
-	* Anyone interested in a language (added it to their profile) can send a message to all interested in the language.	+	* Anyone interested in a language (added it to their profile) can send a message to all interested in the language.
-	* Limit announcements to language and site admins.	+	* Limit announcements to language and site admins.

-	= Announcements interface =	+	==== Announcements interface ====
		+
		+	* A report on site
		+
		+	* Emails
		+
		+	* RSS feeds.

-	* A report on site
-	* Emails
-	* RSS feeds.

developers:bug_days

Thu, 19 Jun 2008 08:15:24 +0000

1201714797		current
Line 1:		Line 1:
	====== Bug Days ======		====== Bug Days ======
		+

	===== Next =====		===== Next =====

-	None scheduled	+	* [[bugday 2008-06-20]]

	===== What is a bug day? =====		===== What is a bug day? =====

developers:bugday_0.8

Wed, 30 Jan 2008 17:39:56 +0000

1201714796		current
Line 11:		Line 11:
	* the code to use is in CVS under the ''translate-toolkit-0-8-branch'' branch. It would help if people have access to CVS so they can quickly test fixes, but if that's too difficult we can try release snapshots as the day progresses.		* the code to use is in CVS under the ''translate-toolkit-0-8-branch'' branch. It would help if people have access to CVS so they can quickly test fixes, but if that's too difficult we can try release snapshots as the day progresses.
	* We will all gather in the #pootle IRC channel on irc.freenode.net		* We will all gather in the #pootle IRC channel on irc.freenode.net
-	* Bugs should be filed at bugs.wordforge.org under "Translate Toolkit"	+	* Bugs should be filed at bugs.locamotion.org under "Translate Toolkit"
	* It would be helpful if people could install the test framework: follow the [[toolkit:index#testing\|testing]] instructions		* It would be helpful if people could install the test framework: follow the [[toolkit:index#testing\|testing]] instructions

developers:bugday_0.9

Wed, 30 Jan 2008 17:39:57 +0000

1201714797		current
Line 10:		Line 10:
	* We will all gather in the #pootle IRC channel on irc.freenode.net		* We will all gather in the #pootle IRC channel on irc.freenode.net
	* It would be great to provide cakes, but they're hard to transport across the net, so you will have to get your own I'm afraid :-)		* It would be great to provide cakes, but they're hard to transport across the net, so you will have to get your own I'm afraid :-)
-	* Bugs should be filed at bugs.wordforge.org under "Translate Toolkit" or "Pootle" respectively.	+	* Bugs should be filed at bugs.locamotion.org under "Translate Toolkit" or "Pootle" respectively.
	* It would be helpful if people could install the test framework: follow the [[toolkit:index#testing\|testing]] instructions		* It would be helpful if people could install the test framework: follow the [[toolkit:index#testing\|testing]] instructions

developers:bugday_2008-06-20

Tue, 24 Jun 2008 09:36:08 +0000

1214299694		current
Line 33:		Line 33:
	* http://translate.svn.sourceforge.net/svnroot/translate/src/trunk/tools/		* http://translate.svn.sourceforge.net/svnroot/translate/src/trunk/tools/
	* http://translate.sourceforge.net/bugdays/20080620/summary.html		* http://translate.sourceforge.net/bugdays/20080620/summary.html
		+


Line 49:		Line 50:
	* Deployment of the new code at http://beta.locamotion.org/ which includes the new indexing code for fast searching, and the ability to translate from an alternative source language.		* Deployment of the new code at http://beta.locamotion.org/ which includes the new indexing code for fast searching, and the ability to translate from an alternative source language.
	* Basically finishing of merging the diet branch and SVN trunk. This is part of the project to improve our scalability, specifically in terms of the way we handle statistics.		* Basically finishing of merging the diet branch and SVN trunk. This is part of the project to improve our scalability, specifically in terms of the way we handle statistics.
		+	* A new testing snapshot of the Translate Toolkit, available for download here: http://translate.sourceforge.net/snapshots/

developers:coding_guidelines

Sat, 27 Sep 2008 08:54:17 +0000

1222505657		current
Line 39:		Line 39:
	For any given project, //proj//, we use the following files and directories (under the main project directory) for the given purposes:		For any given project, //proj//, we use the following files and directories (under the main project directory) for the given purposes:
	* ''//proj//''/ - The sub-directory with the same name as the project, containing the program's source tree. The directory structure below this level depends on the project.		* ''//proj//''/ - The sub-directory with the same name as the project, containing the program's source tree. The directory structure below this level depends on the project.
-	* ''devsupport''/ - This is where any source files should go that is used during development or optional at runtime. Profiling and specific utility code should go here.	+	* ''devsupport''/ - This is where any source files should go that are used during development or optional at runtime. Profiling and specific utility code should go here.
	* ''share///proj///'' - Any resource files that should be installed (typically in ''/usr/share///proj///'' on *nix), but are not source files. For example GUI files, icons, data files.		* ''share///proj///'' - Any resource files that should be installed (typically in ''/usr/share///proj///'' on *nix), but are not source files. For example GUI files, icons, data files.
	* ''run_//proj//.py'' - The main execution script. //(This will likely change in the future)//		* ''run_//proj//.py'' - The main execution script. //(This will likely change in the future)//

developers:commit_guidelines

Mon, 13 Oct 2008 10:22:33 +0000

1223895577		current
Line 1:		Line 1:
	====== Commit guidelines ======		====== Commit guidelines ======
-	This page describes some basic rules for committing to the version control system. Although these are just guidelines, they should be useful most of the time. Above all, let's make it work. If following these guidelines will causes more harm than good, obviously we need to keep our main goals into account.	+	This page describes some basic rules for committing to the version control system. Although these are just guidelines, they should be useful most of the time. Above all, let's make it work. If following these guidelines will cause more harm than good, obviously we need to keep our main goals into account.

	===== Where/when to commit =====		===== Where/when to commit =====

developers:django-pootle

Thu, 26 Nov 2009 09:03:51 +0000

1258927812		current
Line 1:		Line 1:
	====== Outstanding Tasks ======		====== Outstanding Tasks ======
-	* pylint cleanup	+	* package for mandriva, fedora, debian, ubuntu
-	* fix update from templates in admin pages for django 1.0	+

	===== Fix Bugs =====		===== Fix Bugs =====

developers:documentation

Fri, 15 May 2009 10:04:26 +0000

1211799517		current
Line 4:		Line 4:

	* [[wp>Pootle]]		* [[wp>Pootle]]
		+	* [[wp>Virtaal]]
	* [[wp>Translate Toolkit]]		* [[wp>Translate Toolkit]]
	* [[http://xliff-tools.freedesktop.org/wiki/\|XLIFF tools]]		* [[http://xliff-tools.freedesktop.org/wiki/\|XLIFF tools]]

developers:git_mirrors

Tue, 11 Nov 2008 12:51:29 +0000

1226407749		current
Line 71:		Line 71:

	===== Notes =====		===== Notes =====
		+
		+	==== Branches ====

	Currently, we only track the SVN trunks of Pootle and the Toolkit. It is possible to get git-svn to follow branches and we might set up our configuration to handle branches if the need arises.		Currently, we only track the SVN trunks of Pootle and the Toolkit. It is possible to get git-svn to follow branches and we might set up our configuration to handle branches if the need arises.
		+
		+	==== Other mirrored projects ====
		+
		+	The [[http://github.com/translateorgza\|translateorgza]] account contains some other projects mirrored from SVN. You can clone these projects by using the method described above.
		+
		+	If we aren't mirroring a project in which you are interested, please send a request to the mailing list.
		+

developers:gsoc2008

Thu, 28 Aug 2008 07:27:15 +0000

1219908393		current
Line 10:		Line 10:

	==== libgettextpo and PO features ====		==== libgettextpo and PO features ====
-	* Student: [[developers/georgeyk/index\|George Yoshikazu Kussumoto]]	+	* Student: [[developers/developers/georgeyk/index\|George Yoshikazu Kussumoto]]
	* mentored by Dwayne Bailey		* mentored by Dwayne Bailey

Line 20:		Line 20:
	==== XLIFF conformance and placeables ====		==== XLIFF conformance and placeables ====

-	* Student: [[developers/enrique/index\|Enrique González Paredes]]	+	* Student: [[developers/developers/enrique/index\|Enrique González Paredes]]
	* mentored by Friedel Wolff		* mentored by Friedel Wolff

developers:gsoc2008_ideas

Thu, 27 Mar 2008 17:10:31 +0000

1207051729		current
Line 7:		Line 7:
	Our software include:		Our software include:
	* [[toolkit:index\|Translate Toolkit]] - this is a set of tools and libraries that allows files to be transformed into translatable formats. Allows translatable formats to be managed and manipulated. The other tools use this as a library to allow management and manipulation of translatable formats.		* [[toolkit:index\|Translate Toolkit]] - this is a set of tools and libraries that allows files to be transformed into translatable formats. Allows translatable formats to be managed and manipulated. The other tools use this as a library to allow management and manipulation of translatable formats.
-	* [[pootle:index\|Pootle]] - this is an online translation and translation management tool used by [[pootle:live_servers\|many projects]] including [[http://www.sunvirtuallab.com:32300/\|OpenOffice.org]] and [[http://translate.creativecommons.org/\|Creative Commons]].	+	* [[pootle:index\|Pootle]] - this is an online translation and translation management tool used by [[pootle:live_servers\|many projects]] including [[http://pootle.sunvirtuallab.com/\|OpenOffice.org]] and [[http://translate.creativecommons.org/\|Creative Commons]].

	Generic skill requirements:		Generic skill requirements:
Line 110:		Line 110:
	* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/storage/tbx.py?view=markup\|TBX]]		* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/storage/tbx.py?view=markup\|TBX]]
	* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/filters/checks.py?view=markup\|quality checkers]]		* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/filters/checks.py?view=markup\|quality checkers]]
-	* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/storage/tbx.py?view=markup\|poglossary]]	+	* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/tools/poterminology.py?view=markup\|poglossary]]

	Further reading:		Further reading:

developers:gsoc2009_ideas

Tue, 10 Mar 2009 14:52:57 +0000

1236616718		current
Line 28:		Line 28:
	You might also want to take a look at the list of ideas from [[gsoc2008_ideas\|2008]].		You might also want to take a look at the list of ideas from [[gsoc2008_ideas\|2008]].

-	===== Port Virtaal to the Mac =====	+	===== Complete the Mac port of Virtaal =====
	Grade: Medium		Grade: Medium

developers:ideas

Thu, 28 Aug 2008 12:32:56 +0000

1217005775		current
Line 8:		Line 8:
	* [[Merge with versioncontrol]] -- moving the merge code from Pootle to the Toolkit		* [[Merge with versioncontrol]] -- moving the merge code from Pootle to the Toolkit
	* Consider using [[http://code.google.com/p/optparse-gui/\|optparse_gui]] for Toolkit commands to provide GUIs for Toolkit tools.		* Consider using [[http://code.google.com/p/optparse-gui/\|optparse_gui]] for Toolkit commands to provide GUIs for Toolkit tools.
		+	* Automated testing - checkout from Subversion and run tests regularly - see [[http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/patchwatcher.sh\|patchwatcher]]

developers:index

Tue, 27 Oct 2009 11:00:01 +0000

1256572823		current
Line 26:		Line 26:
	* Read about [[http://ldn.linuxfoundation.org/lsb\|portability]]		* Read about [[http://ldn.linuxfoundation.org/lsb\|portability]]
	* [[Project statistics]]		* [[Project statistics]]
		+
		+
		+	===== Product-specific Sections =====
		+
		+	* [[developers:virtaal:index\|Virtaal]]
		+	* [[developers:virtaal:plugin_terminology_plugins\|Terminology back-ends]]

developers:jtoolkit-migration

Fri, 12 Dec 2008 11:08:00 +0000

1207486818		current
Line 1:		Line 1:
	====== Migrate Pootle away from jToolkit ======		====== Migrate Pootle away from jToolkit ======
		+
		+	<note warning>The information on this page is kept for historical
		+	interest. Pootle is in the process of being ported to Django. See
		+	[[developers:The Great Pootle Migration]].</note>

	Since the [[http://jtoolkit.sourceforge.net/\|jToolkit]] is not under active development anymore, it is necessary to move Pootle to a modern web framework.		Since the [[http://jtoolkit.sourceforge.net/\|jToolkit]] is not under active development anymore, it is necessary to move Pootle to a modern web framework.

developers:mailing_lists

Wed, 18 Feb 2009 06:08:37 +0000

1232948988		current
Line 12:		Line 12:
	<form action="http://markmail.org/search/list:net.sourceforge.lists.translate-pootle">Pootle: <input type="text" name="q" size="50"/> <input type="submit" value="Search"/> </form> <br/>		<form action="http://markmail.org/search/list:net.sourceforge.lists.translate-pootle">Pootle: <input type="text" name="q" size="50"/> <input type="submit" value="Search"/> </form> <br/>

-	<form action="http://markmail.org/search/list:net.sourceforge.lists.translate-commits">commits: <input type="text" name="q" size="50"/> <input type="submit" value="Search"/> </form>	+	<form action="http://markmail.org/search/list:net.sourceforge.lists.translate-cvs">commits: <input type="text" name="q" size="50"/> <input type="submit" value="Search"/> </form>
	</html>		</html>

developers:merge_with_versioncontrol

Thu, 24 Jul 2008 08:12:30 +0000

1216834630		current
Line 16:		Line 16:

	===== Update =====		===== Update =====
-	This function commits a local file to the revision control system.	+	This function updates a local file by merging changes from the repository.
	It should handle po files and xliff files.		It should handle po files and xliff files.

developers:mini_projects

Fri, 15 May 2009 10:33:33 +0000

1231246570		current
Line 62:		Line 62:
	===== Glossary Populator =====		===== Glossary Populator =====

-	Or glossary guesser. Use statistical techniques to take an empty glossary file and using your existing translation try to guess what might be a glossary word.	+	Think of this as a glossary guesser. Use statistical techniques to take an empty glossary file and using your existing translation try to guess what might be a translation for a glossary entry.

-	The simple case is the single word entry in translations. The harder case would be where the word occurs in a sentence or paragraph	+	The simple case is where the term occurs on its own in translations. The harder case would be where the word occurs in a sentence or paragraph. Some initial work is already in place in [[toolkit:poterminology]]. Obviously plain TM approaches can also get you started (look into [[toolkit:pot2po]]).

developers:mozootle

Fri, 12 Dec 2008 11:08:56 +0000

1229069632		current
Line 1:		Line 1:
	====== Mozootle ======		====== Mozootle ======
		+
		+	<note warning>The Mozootle code has been merged into the trunk.
		+	Pootle is in the process of being ported to Django. See
		+	[[developers:The Great Pootle Migration]].</note>

	Mozootle is a branch of Pootle development as part of Mozilla's [[https://wiki.mozilla.org/Verbatim\|Verbatim]] project. This page contains notes and planning for developers about merging of the Mozootle branch into the main development line of Pootle.		Mozootle is a branch of Pootle development as part of Mozilla's [[https://wiki.mozilla.org/Verbatim\|Verbatim]] project. This page contains notes and planning for developers about merging of the Mozootle branch into the main development line of Pootle.

developers:mozootle_migration_path

Fri, 12 Dec 2008 11:10:37 +0000

1227863061		current
Line 1:		Line 1:
	====== Mozoolte Django migration ======		====== Mozoolte Django migration ======
		+
		+	<note warning>The information on this page is kept for historical
		+	interest. Pootle is in the process of being ported to Django. See
		+	[[developers:The Great Pootle Migration]].</note>

	This page documents steps we can take in the initial migration of [[developers:Mozootle]] to [[http://www.djangoproject.com/\|Django]]. The motivation is a reduction in pain.		This page documents steps we can take in the initial migration of [[developers:Mozootle]] to [[http://www.djangoproject.com/\|Django]]. The motivation is a reduction in pain.

developers:ohloh

Sat, 27 Sep 2008 10:24:14 +0000

	current
Line 1:	Line 1:
	+	====== Ohloh - Project analysis ======

	+	All of our projects are listed on Ohloh, this provides some interesting statistics about the licensing, health and contributors to the various tools:
	+
	+	* [[http://www.ohloh.net/projects/pootle\|Pootle]]
	+	* [[http://www.ohloh.net/projects/translate-toolkit\|Translate Toolkit]]
	+	* [[http://www.ohloh.net/projects/virtaal\|Virtaal]]
	+	* [[http://www.ohloh.net/projects/spelt\|Spelt]]
	+	* [[http://www.ohloh.net/projects/corpuscatcher\|CorpusCatcher]]

developers:pootle_hig

Fri, 06 Nov 2009 15:44:24 +0000

1256573561		current
Line 25:		Line 25:
	==== Wordings ====		==== Wordings ====
	These are some word choices to take note of:		These are some word choices to take note of:
-	* Admin - fine?	+	* Admin - fine? (ambiguous between administrate and administrator, and we don't have msgctxt really)
	* rights -> permissions		* rights -> permissions

developers:pootleparty2009

Thu, 12 Feb 2009 11:01:20 +0000

1234433454		current
Line 8:		Line 8:
	The meeting will most likely take place at the offices of Translate.org.za in Pretoria with opportunities to visit some sights in Pretoria before / during / after the event. If you have time we recommend that you stay on and visit the site in South Africa (its out of season and the weather is good).		The meeting will most likely take place at the offices of Translate.org.za in Pretoria with opportunities to visit some sights in Pretoria before / during / after the event. If you have time we recommend that you stay on and visit the site in South Africa (its out of season and the weather is good).

-	No registration fee will be charged for attending the event. Travel and accommodation will be for your own account. We can help you to find accommodation here, and can help with other administrative issues in South Africa. Write to the Pootle mailing list urgently (February 2009) if you want to come.	+	No registration fee will be charged for attending the event. Travel and accommodation will be for your own account. We can help you to find accommodation here, and can help with other administrative issues in South Africa. Write to the translate-devel mailing list urgently (February 2009) if you want to come.
		+
		+
		+	To wet your appetite, read more about Pretoria on Wikipedia: http://en.wikipedia.org/wiki/Pretoria

developers:project_statistics

Wed, 04 Feb 2009 05:54:50 +0000

		current
Line 1:		Line 1:
		+	{{rss>http://sourceforge.net/export/rss2_projsummary.php?group_id=91920}}

developers:release

Wed, 03 Dec 2008 11:46:20 +0000

1223325955		current
Line 35:		Line 35:
	* Run ./bin/create-sitemaps		* Run ./bin/create-sitemaps

		+	===== How to run the tools =====
		+
		+	* You need to be the user 'builder'
		+	* The easiest way to do this is by running 'sudo -u builder bash'
		+	* Run bin/snapshot-toolkit to build the toolkit
		+	* If you want to build from a branch, pass the name of the branch (and not the full Subversion URL) as a command line parameter.
		+	* TBD

	===== Afterwards =====		===== Afterwards =====

developers:reporting_bugs

Fri, 04 Jan 2008 13:54:00 +0000

1199528481		current
Line 5:		Line 5:
	If you need help in using the tools, you can consult the [[:developers:mailing_lists\|mailing lists]] or the [[irc://irc.freenode.net/#pootle\|#pootle]] IRC channel.		If you need help in using the tools, you can consult the [[:developers:mailing_lists\|mailing lists]] or the [[irc://irc.freenode.net/#pootle\|#pootle]] IRC channel.

-	If you feel you found a bug, please make sure you are aware of the bug etiquette explained below. Then report your bugs at [[http://bugs.wordforge.org/\|bugs.wordforge.org]] under the relevant "Translate Toolkit", "Pootle", etc. components.	+	If you feel you found a bug, please make sure you are aware of the bug etiquette explained below. Then report your bugs at [[http://bugs.locamotion.org/\|bugs.locamotion.org]] under the relevant "Translate Toolkit", "Pootle", etc. components.

	===== Bug Etiquette =====		===== Bug Etiquette =====

developers:screencast_script_mozilla_pootle

Fri, 09 May 2008 07:14:06 +0000

	current
Line 1:	Line 1:
	+	Welcome to the Mozilla Pootle Demo
	+
	+	In this demo we are visiting some of the features of Pootle including translating, making suggestions and reviewing suggestions. We will not be examining any of the admin functionality
	+
	+	We are on the front page of Pootle where you can see all the current languages available for translation on this server. You can also see a list of projects that may be translated. We will be translating the 'Mozilla demo' project. [Press Mozilla Demo]
	+
	+	Two languages are enabled: [point] Afrikaans and French.
	+	You can see the current translation status in the table. We use word counts instead of strings as this gives a better indication of the amount of work remaining.
	+	We can see counts for translated [point], fuzzy [poiny] (these are items that need to be checked by a translator and won't appear in the application in this state), and translated [point]
	+	A graph [point] gives a simple visual indication of the status.
	+	The table itself may be sorted on any of the field e.g. language, assending [click] or descending [click]
	+
	+	Lets begin doing some translations in Afrikaans [Click on Afrikaans]
	+
	+	You can see in the first three files that we are processing a .dtd [point], .properties [point] and .ini [point] file. These would have been preprossed from Mozilla sources by the Pootle administrator.
	+
	+	To begin translating we click on [Show editing functions].
	+	Yes the interface is quite busy but once you understand that the grey bar at the top [point around] refers to all the current files and directories.
	+	And each row [point around] is a file or directory things get simpler.
	+	Each row will give you the status of that particular file [point to the top]. We have 5 files and we are 16% complete. You'll notice that here we also provide string counts [point]
	+
	+	In each row we can see a number of editing functions. For now we are only interested in [point] Quick Translate. This allows us to step through the files visiting only strings that need attention. Lets translate [click] on a.dtd's quick translate.
	+
	+	In translation mode we have the original text (also called the source text) on the left. The words that we need to translate is [File].
	+
	+	On the right is our [point] editing widget. We can [point] go back, skip this entry, copy the original text, make a suggestion or submit a translation. We will translate this text. The translation is [type] Leer.
	+	That's not quite correct as I don't have an Afrikaans keyboard. I'll use the special character [point] to fix the entry. Now we're ready and we [sumbit] our first translation. [Click back to stats] a.dtd in now fully translated.
	+
	+	For the next entries we will quick translate across all files. So we select [Quick Translate] from the navigation bar. And we start translating [Eerste] and [submit]. This one I'm not sure about so I submit a suggestion.
	+
	+	You'll notice that we started on another file. On the right [point] your can see suggestions that are being pulled from our terminology file. We can click on the suggestion and reuse it [click]. This ensures consistency throughout the translations. And again we use a suggestion for 'Edit'.
	+
	+	This one looks way too hard for now. Lets skip it [click].
	+
	+	Back to our stats and we're looking good.
	+
	+	You remember that we made a suggestion. Lets see how you can review suggestions. You could use suggsetions to enter items that you want someone to review or to expose your translations for bug reports and ad hoc translators. Back to the editing functions [click]

developers:screencasts

Thu, 26 Mar 2009 09:00:06 +0000

1234445031		current
Line 7:		Line 7:
	===== Tools =====		===== Tools =====

-	* [[http://recordmydesktop.iovar.org/about.php\|recordMyDesktop]] - this is about the easiest to use.	+	* [[http://recordmydesktop.sourceforge.net/about.php\|recordMyDesktop]] - this is about the easiest to use.
	* [[http://xvidcap.sourceforge.net/\|xvidcap]] - very nice interface design but didn't actually record anything		* [[http://xvidcap.sourceforge.net/\|xvidcap]] - very nice interface design but didn't actually record anything

developers:sidebar

Fri, 24 Jul 2009 16:25:48 +0000

1242659502		current
Line 11:		Line 11:
	* [[:virtaal:index\|Virtaal]]		* [[:virtaal:index\|Virtaal]]
	* [[:guide:start\|Localisation Guide]]		* [[:guide:start\|Localisation Guide]]
-
-	======
-	<html>
-	<a href="http://sourceforge.net/community/cca09/nominate/?project_name=Pootle, Virtaal & The Translate Toolkit&project_url=http://sourceforge.net/projects/translate/"><img src="http://sourceforge.net/images/cca/cca_nominate.png" border="0"/></a>
-	</html>
-
-
-

	=====		=====

developers:snapshots

Fri, 18 Apr 2008 08:24:24 +0000

	current
Line 1:	Line 1:
	+	====== Creating snapshots ======
	+
	+	These instructions are for ad hoc or developer snapshots. If you are doing an official release please check the [[release\|release checklist]].
	+
	+	* Up the version number in %%__version__.py%%
	+	* On sourceforge run ~/translate/bin/snapshot-toolkit or snapshot-pootle

developers:styling

Wed, 19 Nov 2008 08:35:58 +0000

	current
Line 1:	Line 1:
	+	====== Styling approach ======
	+	This page describes some approaches to styling with specific attention to language specific requirements, and right-to-left layout. This is mostly applicable to Pootle, but several aspects probably apply wider as well.

	+	===== Language specific styling =====
	+	The CSS for Pootle specifies some styling that are specific to languages. Some of them are based on [[l10n:displaysettings\|requests from translators]]. It affects readibility (sometimes in crucial ways), but generally helps to provide a better user interface and nice translation environment.
	+
	+	The crucial point is that text should always be marked to be in the language that it is. The language specific styling will apply to the element where it is marked with a lang= attribute, and unless some specific styling is overridden, will be inherited by children. Since Pootle's content (especially on the translation page) necessarily contains mixed language content, care must be taken to ensure that all elements are correctly marked up to ensure the correct display settings. This obviously is also better for accessibility, etc.
	+
	+	Default strings (such as the default welcome message) will probably be in English, and should be styled as English to ensure good display in a non-English interface.
	+
	+	The :lang() CSS selector is maybe not supported by some versions of some obscure browsers (like IE). We might care or not.
	+
	+	===== RTL =====
	+	Most modern browsers do much better with RTL than some years ago, although there seems to be huge amounts of corner cases and slightly broken issues. Pootle needs to work correctly for all RTL languages including handling all pages with mixed content such as the translate page.
	+
	+	Since some features are just broken for RTL in some browsers, one might assume that most users needing this might be using better browsers, and therefore we can style the default for LTR and override as needed for RTL.
	+
	+	The general approach is to mirror as much as possible, while keeping in mind that certain important elements (such as the server name, welcome message, project names and descriptions) might still be in English and styling of these elements needs to be reviewed to make sure they make work well. Whereas layout for LTR will probably reflect the idea of some left-to-right workflow, the whole workflow should probably be done right-to-left in the RTL interface. In some cases this works very well. For exapmle, English and Arabic on the translatepage with RTL interface causes the strings to all be aligned in the middle of the table, which is nice for review.
	+
	+	Elements floating right in LTR are marked explicitly with a dir= attribute, since they will have to be styled explicitly, and you can't select with CSS on the inherited directionality.
	+
	+	Margins and borders need to be reviewed. A border on the left only (for example) must be changed to a right border for RTL, but if the default (LTR) CSS rule will still apply, the left border also has to be removed.
	+
	+	Default strings (such as the default welcome message) will probably be in English, and should be marked as LTR to ensure good display in the RTL interface.

developers:the_great_pootle_migration

Tue, 17 Nov 2009 16:21:04 +0000

1233930363		current
Line 1:		Line 1:
	====== The Great Pootle Migration ======		====== The Great Pootle Migration ======
		+
		+	<note warning>This page is outdated. There is a [[developers:django-pootle\|specific page]] for listing outstanding tasks and enhancements for the future in the Django-based Pootle.</note>

	===== What's been done so far =====		===== What's been done so far =====

developers:tm_server

Fri, 15 May 2009 09:47:01 +0000

1228152650		current
Line 1:		Line 1:
-	plan for a standalone TM server.	+	This project is about writing a standalone [[toolkit:tmserver\|TM server]].
		+
		+	<note>This project has been implemented, and was released with version 1.3 of the Translate Toolkit, and integrated into Virtaal version 0.3. Many further developments remain possible - feel free to get involved with this exciting project.</note>

	===== Rationale =====		===== Rationale =====
-	* is probably easier to implement for virtaal that messing with multiple threads	+	* It is probably easier to implement for Virtaal than messing with multiple threads
-	* useful for both virtaal and pootle	+	* It is useful for both Virtaal and Pootle
-	* allows single shared TM server between different pootle/virtaal instances	+	* It allows single shared TM server between different Pootle/Virtaal instances
	===== Design =====		===== Design =====
-	* tiny http server (using wsig)	+	* Tiny http server (using wsig)
-	* exchanges messages using JSON	+	* Exchanges messages using JSON
-	* no that's not overkill you're just too old to recognize it	+
	===== Tasks =====		===== Tasks =====
	* <del>build very basic that can be tested with a webbrowser</del>		* <del>build very basic that can be tested with a webbrowser</del>
	* <del>basic server can respond to a single TM query at a time</del>		* <del>basic server can respond to a single TM query at a time</del>
-	* implement TM update feature	+	* <del>implement TM update feature</del>
-	* build a skeleton GTK test application to experiment with different queue and timing options	+	* <del>build a skeleton GTK test application to experiment with different queue and timing options</del> (Not in version control, ask Alaa if you are interested)
-	* scale to many consecutive requests	+	* scale to many consecutive requests (done?)
-	* build virtaal MVC module	+	* <del>build virtaal MVC module</del>

		+	===== Future =====
		+	* Ignoring some placeables to provide better matches
		+	* Accepting rich strings in the API
		+	* Providing rich strings
		+	* More meta-data for stored translations
		+	* TMX export

developers:translation

Fri, 25 Jul 2008 08:46:29 +0000

1216975453		current
Line 12:		Line 12:
	\| [[:start\|Front page]] \| \| \|		\| [[:start\|Front page]] \| \| \|
	\| [[users:user_guide\|Pootle user's guide]] \| \| Needs a lot of cleanup \|		\| [[users:user_guide\|Pootle user's guide]] \| \| Needs a lot of cleanup \|
-	\| [[pootle:admin\|Pootle admin guide]] \| \| This and the other guides need to be created. \|	+	\| [[pootle:site_administrator_s_guide\|Pootle site admin guide]] \| \| This and the other guides need to be created. \|
	\| [[guide:start\|Localisation guide]] \| \| We probably want to look at the front page and reorder pages. Some data needs to be reviewed and cleaned up.\|		\| [[guide:start\|Localisation guide]] \| \| We probably want to look at the front page and reorder pages. Some data needs to be reviewed and cleaned up.\|
	\| [[toolkit:index\|Translate Toolkit]] \| This might be the best first start, especially the guides. \| Very good condition. We probably want to make the toolkit itself localisable before looking at all the man pages. \|		\| [[toolkit:index\|Translate Toolkit]] \| This might be the best first start, especially the guides. \| Very good condition. We probably want to make the toolkit itself localisable before looking at all the man pages. \|
Line 20:		Line 20:

	* [[developers:index\|Developer pages]]		* [[developers:index\|Developer pages]]
		+
		+	===== Issues =====
		+
		+	* Images - how will we localise images?
		+	* Automation - we still need to build the automation that will push the new translations to a Pootle server.
		+

developers:translation_memory_database

Fri, 15 May 2009 10:42:40 +0000

1242383417		current
Line 4:		Line 4:

	<note>		<note>
-	A Translation Memory database was implemented and is already in use by [[toolkit:tmserver]] and therefore also [[virtaal:index\|Virtaal]]. It did not use many of these principles, so this page is mostly for reference. Consult the source code and/or the developers about the TM database or using the TM server.	+	A Translation Memory database was implemented and is already in use by [[toolkit:tmserver]] and therefore also [[virtaal:index\|Virtaal]]. It does not use all of these principles and ideas, so this page is mostly to collect ideas for future possibilities. Consult the source code and/or the developers about the TM database or using the TM server.
	</note>		</note>

Line 39:		Line 39:
	* Date:		* Date:

-		+	==== Pre calculation principle ====
-	===== Pre calculation principle =====	+

	The idea of using the warehouse is that we only check distances on source text. This source text is mostly unchanging (not quite true as it is slowly moving). Thus it is possible to gather all source text and pre calculate distances. As target text is created it can be linked to source text by the pre calculated distances.		The idea of using the warehouse is that we only check distances on source text. This source text is mostly unchanging (not quite true as it is slowly moving). Thus it is possible to gather all source text and pre calculate distances. As target text is created it can be linked to source text by the pre calculated distances.
Line 57:		Line 56:


-	===== Things to explore =====	+	==== Things to explore ====

-	==== Rapid processing of new entries by not matching everything ====	+	=== Rapid processing of new entries by not matching everything ===

	Is it possible to add new database entries without matching them against every single database entry. Thus if you had 10,000 entries and you want to add a new match would it be possible to find a close match and compare the string to the surrounding matches to satisfy the distance calculations. Or must you match against all entries?		Is it possible to add new database entries without matching them against every single database entry. Thus if you had 10,000 entries and you want to add a new match would it be possible to find a close match and compare the string to the surrounding matches to satisfy the distance calculations. Or must you match against all entries?

		+
		+	===== Full text indexing =====
		+	This is the approach currently used in [[toolkit:tmserver]]. When the full text indexing is available in the underlying database, it is used to speed up the initial process of finding possible suggestions. Post-processing ensures that the good scoring is still used to select and rank the final set of suggestions.
		+
		+	There are some shortcomings to this approach, mostly enforced by the full text indexing of the database. For sqlite, the fts3 module is optional, new and does not support stemming for anything but English (using the Porter stemmer). In the default install of MySQL, words shorter than four characters are not indexed. This setting can be changed, but is a server-wide setting with obvious implications.
		+
		+	Obviously full text indexing has serious limitations for several languages. Since we are more concerned about the applicability for English (as the most common source language used in our tools), this is not terrible, but definitely not ideal.
		+
		+	Friedel has conceptual model to work around the limitations of full text indexing as explained above. Nothing has been implemented yet. Contact him if you are interested.

developers:use_kid_with_django

Mon, 03 Nov 2008 14:37:20 +0000

1225722873		current
Line 58:		Line 58:
	In the above code, since we only have the directory 'templates' in		In the above code, since we only have the directory 'templates' in
	settings.TEMPLATE_DIRS, the file ''start.kid'' must appear at		settings.TEMPLATE_DIRS, the file ''start.kid'' must appear at
-	''templates/start.kid''.	+	''templates/start.kid''. ''pagetitle'' is a template variable.

	<html>		<html>

developers:version_1_2_1_release

Thu, 04 Dec 2008 06:31:38 +0000

1228305122		current
Line 34:		Line 34:
	* Enable / disable enabled languages in pootle.prefs		* Enable / disable enabled languages in pootle.prefs
	* Any new scripts / packages to be specified in setup files?		* Any new scripts / packages to be specified in setup files?
-	* up version number
	* test		* test
	* update ChangeLog (do an svn up first in the directory where svn2cl is run from, otherwise you don't get the latest entries)		* update ChangeLog (do an svn up first in the directory where svn2cl is run from, otherwise you don't get the latest entries)
	* build		* build
-	* verify that latest changes are in if the build is checked out with anonymous CVS
	* Documentation: epydoc?		* Documentation: epydoc?
	* sanity checks		* sanity checks
-	* install on http://pootle.locamotion.org/
	* Add the version in http://bugs.locamotion.org/		* Add the version in http://bugs.locamotion.org/
	* Sourceforge		* Sourceforge

developers:virtaal_mvc

Fri, 15 May 2009 09:41:03 +0000

1228753600		current
Line 1:		Line 1:
		+	<note>This project has been completed before the release of version 0.3, and the current development versions of Virtaal mostly follow this design.</note>
		+
	====== Introduction ======		====== Introduction ======
	This is the specification for the major architectural changes implemented for Virtaal 0.3. The main aim of these changes is to create a stable, robust and easy-to-use platform from which all the future changes can be easily implemented. For this purpose it has been decided to use a [[wp>Model-view-controller\|MVC]] architecture.		This is the specification for the major architectural changes implemented for Virtaal 0.3. The main aim of these changes is to create a stable, robust and easy-to-use platform from which all the future changes can be easily implemented. For this purpose it has been decided to use a [[wp>Model-view-controller\|MVC]] architecture.

developers:virtaal_mvc_draft

Mon, 08 Dec 2008 14:16:18 +0000

	current
Line 1:	Line 1:
	+	<note>This page is a draft.</note>

	+	====== Introduction ======
	+	This is a draft specification for the major architectural changes planned for Virtaal 0.3. The main aim of these changes is to create a stable, robust and easy-to-use platform from which all the future changes can be easily implemented. For this purpose it has been decided to use a [[wp>Model-view-controller\|MVC]] architecture.
	+
	+	While this page is in its draft stage all statements made herein should be considered suggestions or opinions. Specific sections, paragraphs or sentences that are not yet decided on will be marked with "(??)".
	+
	+
	+	====== Architecture ======
	+	===== MVC =====
	+	To reach the goals stated in the introduction above we will be implementing a [[wp>Model-view-controller\|MVC]] architecture in the code. See the diagram below for the proposed architectural structure.
	+
	+	==== Diagram ====
	+	{{:developers:virtaal-mvc1.png\|Virtaal's MVC architecture}}
	+
	+	==== Description ====
	+	With a basic understanding of the MVC pattern as well as knowledge of Virtaal's features, the diagram should be reasonably self-explanitory. The following description contains notes about unexpected, unclear or new concepts introduced.
	+
	+	The ''Store'' group in the diagram represents the model, view and controller that is related to store-level activities. In terms of the GUI, the ''StoreView'' would be the main ''gtk.TreeView'' widget as it is in Virtaal 0.2. The ''StoreModel'' is a basic wrapper for basic translation store which (mainly) handles the loading, saving and parsing of translation files.
	+
	+	Similarly the ''Unit'' group represents the unit-level components. The ''UnitView'' specifically represents the GUI of the unit editor (the selected unit) as it is in Virtaal 0.2.
	+
	+	The ''Mode'' MVC-triplet produces a ''ModeCursor'' that specifies which units are usable in the currently selected mode. This cursor will be used by the ''StoreController'' and/or ''UnitController''.
	+
	+	The ''MainWindow'' object is responsible for managing the creation of the other main components and may also serve as proxy for communications where no "official" channel is available(??).
	+
	+
	+	===== Extensions =====
	+	Adding features to Virtaal will be much easier once this architecture is in place. The //way// in which this is done can make the difference between a nice, modular system and a convoluted mountain of messy code. Extensions can be done in one of three ways(??):
	+	* Extending relevant, existing component(s). This is typically how basic functionality will be implemented.
	+	* As separate MVC modules. Using this approach, a feature (or extension) creates its own model(s), view(s) and/or controller. These components then connect to the signals they are interested in, in order to connect themselves to the system. This should be the preferred method for bigger, more complicated features such as translation memory.(??)
	+	* As plug-ins. Separate classes (possibly also with a MVC design) that are dynamically loaded and connects to signals of the existing components in order to connect to the system. This approach should be used by smaller, non-critical features.(??)
	+
	+
	+
	+	====== Source Code ======
	+	This section contains specifications for all source code-related issues. Please add any missing info.
	+
	+	===== Naming conventions =====
	+	==== Classes ====
	+	As per [[http://www.python.org/dev/peps/pep-0008/\|PEP 8]] class names are written in camel case, starting with a capital letter.
	+	==== Variables ====
	+	As per [[http://www.python.org/dev/peps/pep-0008/\|PEP 8]], as well as existing conventions in the Translate Toolkit and Virtaal, variable names are all-lower case and words should be split with underscores.
	+
	+	Names of variables representing Gtk+ widgets should have a prefix describing the type of widget it represents. Here are some prefixes:
	+	\| //btn// \| ''gtk.Button'' \|
	+	\| //cmb// \| ''gtk.ComboBox'' \|
	+	\| //mnu// \| ''gtk.MenuItem'' \|
	+	\| //tvw// \| ''gtk.TreeView'' \|
	+	\| //txt// \| ''gtk.TextView'' \|
	+	\| //wnd// \| ''gtk.Window'' \|
	+	(??)
	+
	+	===== Formatting =====
	+	* Lines containing only comments or documentation strings should not be exceed 80 characters.
	+	* Long lines containing code should be formatted to maximise readability.
	+	* As a rule there should be only one class per file. Exceptions are allowed in cases where there are small, related classes grouped into a single file.
	+	* When in doubt, refer to [[http://www.python.org/dev/peps/pep-0008/\|PEP 8]]
	+	* If still in doubt, follow the conventions used so far.
	+	* If still in doubt, ask a dev!
	+	==== Comments ====
	+	* Comments should be written //while// coding and not afterwards.
	+	* Missing features, obvious bugs or other important notes should immediately be marked with a FIXME, TODO or XXX mark in a comment.
	+	* Refrain from adding obvious comments except where used to label separate blocks of code.
	+	==== Documentation strings ====
	+	* Epydoc-compatible document strings should be added where possible. This includes file- and class-level docstrings.
	+	* Inside classes at least all public and weak-private (one leading underscore) methods should be documented.(??)
	+	* Method and function documentation strings must at least specify type parameters (the ''@type'' directive) and the return value if not ''None'', except where these are very obvious.
	+	==== Imports ====
	+	* Relative imports should not be used. This allows for much more clarity where scope of an imported class/function/variable is concerned.
	+	* Imports should always be grouped in the following order (separated by a blank line):
	+	* System/global module
	+	* Inter-Virtaal / inter-module
	+	* Intra-module (other files in the same module)
	+
	+	===== Tests =====
	+	* Even though it is not time-efficient to write tests for absolutely everything, there should at least be tests for the most important functionality of a class/module.
	+	* Tests should be grouped into test classes that test either a specific (large and important) class or a specific module.
	+
	+	===== File Layout =====
	+	This is section is only applicable to the ''virtaal/'' source sub-directory, seeing as the rest of the directory structure is serving us quite well.
	+
	+	Related code should definitely be grouped together into modules and sub-modules. Here are some possibilities:
	+	* Create sub-directories for ''models'', ''views'' and ''controllers'' and put the files containing the relevant classes in each of those directories. Example for unit-related class files: ''models/unitmodel.py'', ''views/unitview.py'', ''controllers/unitcontroller.py''
	+	* Create a separate (sub-)module for each MVC group of files/classes. This would mean the creation of at least the ''store'', ''unit'' and ''mode'' sub-directories. Example for unit-related class files: ''unit/unitmodel.py'', ''unit/unitview.py'', ''unit/unitcontroller.py''
	+	(??)
	+
	+	Note that there is no mention of a plug-ins directory, because it has not been decided if plug-ins will be supported.
	+
	+
	+
	+	====== Documentation ======
	+	API documentation should be generated from the epydoc documentation strings in the source code. Other, more descriptive documentation should be maintained on the wiki.
	+
	+
	+
	+	====== Implementation Planning ======
	+	Seeing as this implementation will affect our planning schedule, the implementation of specific parts of the code should be ordered in such a way that other planned work can be started as soon as possible.
	+
	+	All implementation should reuse as much code as possible from Virtaal 0.2 in order to save development time.
	+
	+	(Note that all time estimations include the writing of tests)
	+
	+	===== Phase 1 =====
	+	* Number of developers: 1
	+	* Estimated time needed: 3 days
	+	* Description: This phase consists of creating basic implementations of the following components (in roughly the order they appear in):
	+	* ''MainWindow''
	+	* ''StoreController'', ''StoreModel'', ''StoreView'' (relatively parallel)
	+	* ''UnitController'', ''UnitModel'', ''UnitView'' (relatively parallel)
	+
	+	===== Phase 2 =====
	+	* Number of developers: 1 or more
	+	* Estimated time needed: 40 developer-hours
	+	* Description: Implement all extra functionality from Virtaal 0.2. Here are some of the specific sub-goals for this phase:
	+	* Implement all mode-related classes. This includes creating ''ModeCursor''s and using them for navigation.
	+	* Implement undo functionality using ''StoreView'' and ''UnitView''.
	+
	+	====== TODO ======
	+	* <del>Undo</del>
	+	* Modes
	+	* <del>Search and</del> replace
	+	* <del>Incomplete</del>
	+	* <del>Spell checking</del>
	+	* <del>AutoCorrection/AutoCompletion</del>
	+	* <del>Add comments and context fields</del>
	+	* <del>Test formats other than PO</del> //Tested with basic XLIFF files.//
	+	* <del>Update headers - ask user for team info</del> //See related bug below.//
	+	* <del>Write tests.</del>
	+	* <del>Generate docs</del>
	+	* <del>Use unit-level ''gettargetlanguage()'' in stead of the store-level equivalent.</del>
	+
	+	===== Bugs =====
	+	* <del>Mode bar visible even if no file is loaded.</del>
	+	* <del>"Save as..." should be inactive until a file is loaded.</del>
	+	* <del>First unit in a file is not selected on load.</del>
	+	* <del>Pressing Enter in a target does not move focus to the next plural textview.</del>
	+	* <del>If the first plural form is changed, the change is not visible after switching to a different unit.</del> //Problem was much bigger than mentioned. No changes to plurals were saved because of ''multistring'''s suckage.//
	+	* <del>Recent files not updating.</del>
	+	* <del>Editing area does not respond to changes in window size.</del> //Could not reproduce//
	+	* Widget heights are not 100% correct for single-row units: too much space at the bottom.
	+	* <del>Opening a second file does not work.</del>
	+	* Excessive flickering when changing units.
	+	* Without specifying your translator e-mail address, each time a file is saved, a contributer heading is added regardless of whether there is one (or more) already. This is probably related to the checks in ''translate.storage.poheader.poheader.updatecontributor()''.

developers:wiki_notes

Mon, 03 Aug 2009 16:14:18 +0000

1249293172		current
Line 1:		Line 1:
	====== Wiki notes ======		====== Wiki notes ======

		+	This gives some help about special links, and special markup for wiki links in this wiki.

	===== Interwiki =====		===== Interwiki =====

1207051729		current
Line 7:		Line 7:
	Our software include:		Our software include:
	* [[toolkit:index\|Translate Toolkit]] - this is a set of tools and libraries that allows files to be transformed into translatable formats. Allows translatable formats to be managed and manipulated. The other tools use this as a library to allow management and manipulation of translatable formats.		* [[toolkit:index\|Translate Toolkit]] - this is a set of tools and libraries that allows files to be transformed into translatable formats. Allows translatable formats to be managed and manipulated. The other tools use this as a library to allow management and manipulation of translatable formats.
-	* [[pootle:index\|Pootle]] - this is an online translation and translation management tool used by [[pootle:live_servers\|many projects]] including [[http://www.sunvirtuallab.com:32300/\|OpenOffice.org]] and [[http://translate.creativecommons.org/\|Creative Commons]].	+	* [[pootle:index\|Pootle]] - this is an online translation and translation management tool used by [[pootle:live_servers\|many projects]] including [[http://pootle.sunvirtuallab.com/\|OpenOffice.org]] and [[http://translate.creativecommons.org/\|Creative Commons]].

	Generic skill requirements:		Generic skill requirements:
Line 110:		Line 110:
	* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/storage/tbx.py?view=markup\|TBX]]		* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/storage/tbx.py?view=markup\|TBX]]
	* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/filters/checks.py?view=markup\|quality checkers]]		* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/filters/checks.py?view=markup\|quality checkers]]
-	* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/storage/tbx.py?view=markup\|poglossary]]	+	* [[http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/tools/poterminology.py?view=markup\|poglossary]]

	Further reading:		Further reading:

1216975453		current
Line 12:		Line 12:
	\| [[:start\|Front page]] \| \| \|		\| [[:start\|Front page]] \| \| \|
	\| [[users:user_guide\|Pootle user's guide]] \| \| Needs a lot of cleanup \|		\| [[users:user_guide\|Pootle user's guide]] \| \| Needs a lot of cleanup \|
-	\| [[pootle:admin\|Pootle admin guide]] \| \| This and the other guides need to be created. \|	+	\| [[pootle:site_administrator_s_guide\|Pootle site admin guide]] \| \| This and the other guides need to be created. \|
	\| [[guide:start\|Localisation guide]] \| \| We probably want to look at the front page and reorder pages. Some data needs to be reviewed and cleaned up.\|		\| [[guide:start\|Localisation guide]] \| \| We probably want to look at the front page and reorder pages. Some data needs to be reviewed and cleaned up.\|
	\| [[toolkit:index\|Translate Toolkit]] \| This might be the best first start, especially the guides. \| Very good condition. We probably want to make the toolkit itself localisable before looking at all the man pages. \|		\| [[toolkit:index\|Translate Toolkit]] \| This might be the best first start, especially the guides. \| Very good condition. We probably want to make the toolkit itself localisable before looking at all the man pages. \|
Line 20:		Line 20:

	* [[developers:index\|Developer pages]]		* [[developers:index\|Developer pages]]
		+
		+	===== Issues =====
		+
		+	* Images - how will we localise images?
		+	* Automation - we still need to build the automation that will push the new translations to a Pootle server.
		+