[geeklog-devel] The road ahead - post 1.5.0

[Blaine Lang]

The XLIFF format for language files looks interesting as the one file 
contains all the translations. Whether we would parse the XML in this 
file or create separate language files from this one file is still a 
good question but I like the idea and it would make a nice SOC project.

I would prefer to see an integrated GL Admin tool to manage the language 
file and remove any pootle and python dependency.
 - update the master XLIFF file translations
 - create the separate language files (assuming that was needed)

This caught my interest as I have been working on an online tool for a 
project so translators could bring up any language file and edit the the 
translations without having to touch the real file.

Blaine

Trinity wrote:
> for a way of translating the lang files as a group project i recommend 
> pootle
> http://translate.sourceforge.net/wiki/pootle/index
>
> it supports converting the resulting .po files to php value arrays in 
> a php file. you can also convert a our lang files into the .po file 
> that this  software uses. it is writen in python and runs as a web 
> based app that can be accessed from anywhere you can plce it.
>
>
> On Thu, Jun 26, 2008 at 1:26 PM, Michael Jervis <mjervis at gmail.com 
> <mailto:mjervis at gmail.com>> wrote:
>
>     > For starters, we should start using the bugtracker more. Mantis
>     has a
>     > few features that we may want to use, e.g. subprojects, custom
>     fields,
>     > and filters.
>
>     OK so do we want to start figuring out which bugs are critical for
>     1.5.[1|0-1] using Mantis and assigning them a status that indicates
>     such and assigning them out?
>
>     Should we then start using Mantis to create a sub-project for
>     1.5.[2|1] with feature requests (or whatever mantis has) to indicate
>     what we should be building for it? Moving bugs we don't plan to fix in
>     1.5.[1|0-1] into fix for that if they are too big or whatever?
>
>
>     > One problem with this: So far, our stance was that we would be
>     > supporting the last two versions (current and previous release), and
>     > that was usually easy to understand from the version numbers.
>
>     Do we reserve version numbers for that then? 1.5.0 has fixes 1.5.1,
>     1.5.2 etc and the next release is 1.6? Since geeklog2 is now aptitude,
>     can we decide when gl1 gets to be GL2? Or does it?
>
>     if we release 1.5.0-1 as a bug fix only release, and we have a
>     security issue, do we have to do 1.5.0sr1 and 1.5.0-1sr1?
>
>
>     > Of course, if we go forward in smaller steps, our users may be less
>     > reluctant to upgrading ...
>
>     There's always that...
>
>     > Depends. Some are very fast, others are only updated every other
>     release.
>     >>Do they necessarily prevent a release?
>     > Depends, again. If there's a new feature with a user interface, we
>     > should at least give the translators a chance.
>     >>Can we provide language file updates
>     >>via Geeklog.net post-release?
>     > Sure - look at our download section. It tends to get cluttered up,
>     > though, and some people may miss them.
>
>     So we could identify "must have" translations where we have a reliable
>     fast translator (such as German ;-)) and make sure the translator
>     knows the road-map in advance and can have plenty of warning as we get
>     ready and thus having the translations will be manageable.
>
>     Anyone else want to chime in? Sounds workable to me...
>     _______________________________________________
>     geeklog-devel mailing list
>     geeklog-devel at lists.geeklog.net
>     <mailto:geeklog-devel at lists.geeklog.net>
>     http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>