New development branch
Dimitris Glezos
http://code.transifex.org/transifex-devel/
Diego has been adding a ton of good stuff on his branch, so I dubbed
it 'devel'. This could be considered the 'main' development branch,
which will eventually turn to our next release. The 'trunk' branch now
uses SQLalchemy, Genshi templates, ToscaWidgets and tw.forms, and
features i18n support and minimal statistics support (a few hours'
work, really). This probably deprecates the -alchemy and -genshi ones,
so unless there is a reason to keep them, we can remove them.
As expected, because of the major changes in the low-level stuff, a
few stuff might not be (read: aren't) working, but we'll slowly hammer
it to something stable. Repositories that would in Tx would probably
want to pull (often) to make merging easier.
In other news, I had a wiki page created for people who would wish to
follow up on News: http://transifex.org/wiki/News. Unfortunately, no
RSS support for Trac wiki pages yet.
-d
--
Dimitris Glezos
Jabber ID: gle...@jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
Stéphane Raimbault
It was about time, so here it is:
http://code.transifex.org/transifex-devel/
Diego has been adding a ton of good stuff on his branch, so I dubbed
it 'devel'. This could be considered the 'main' development branch,
which will eventually turn to our next release. The 'trunk' branch now
uses SQLalchemy, Genshi templates, ToscaWidgets and tw.forms, and
features i18n support and minimal statistics support (a few hours'
work, really).
I switched my dev on this branch, so my .plan:
1 - new model with some tables required by Vertimus
2 - adapt my kid layout to Genshi (for Fedora and GNOME)
3 - integrate the business logic of Vertimus in Transifex.
I'm going to push my patches to you at each step.
Do you intend to rewrite the VCS abstraction with an object design?
Stéphane
Dimitris Glezos
This is good news, having a common codebase and roadmap from now on.
You might also want to take a look at a doc we put together with a
proposed workflow for such changes [1]. Do we have any featureset and
plan for bullet 3, just to make sure we don't have duplicated work?
> Do you intend to rewrite the VCS abstraction with an object design?
Christos is working on this as part of his Google Summer of Code. I
can say with pure confidence that some parts of Tx need major
re-engineering, especially the ones that were developed early on, when
I was still learning Python. :)
-d
[1]: http://transifex.org/wiki/Development/Workflow
Stéphane Raimbault
This is good news, having a common codebase and roadmap from now on.
> I switched my dev on this branch, so my .plan:
> 1 - new model with some tables required by Vertimus
> 2 - adapt my kid layout to Genshi (for Fedora and GNOME)
> 3 - integrate the business logic of Vertimus in Transifex.
>
> I'm going to push my patches to you at each step.
You might also want to take a look at a doc we put together with a
proposed workflow for such changes [1]. Do we have any featureset and
plan for bullet 3, just to make sure we don't have duplicated work?
The essential part of bullet 3 is a design pattern "State" around the class Module.
I begin to rewrite this part in Python on my Launchpad branch.
I've just take an hour to work on the bullet 1, I'm about to find stupid my model tomorrow ;) but before that, you can take look at the new model (attached SVG file).
I also joined a draft of model.py (don't try tg-admin sql create on it because the classes are not included).
Stéphane
PS: I studied Genshi and it's rocks!
Stéphane Raimbault
2008/6/18 Dimitris Glezos <dimi...@glezos.com>:This is good news, having a common codebase and roadmap from now on.
> I switched my dev on this branch, so my .plan:
> 1 - new model with some tables required by Vertimus
> 2 - adapt my kid layout to Genshi (for Fedora and GNOME)
> 3 - integrate the business logic of Vertimus in Transifex.
>
> I'm going to push my patches to you at each step.
You might also want to take a look at a doc we put together with a
proposed workflow for such changes [1]. Do we have any featureset and
plan for bullet 3, just to make sure we don't have duplicated work?
PS: I don't think it's a good idea to have so many Unicode fields when it's not necessary (for perf).
Dimitris Glezos
<stephane....@gmail.com> wrote:
> 2008/6/18 Dimitris Glezos <dimi...@glezos.com>:
>>
>> On Tue, Jun 17, 2008 at 5:01 PM, Stéphane Raimbault
>> <stephane....@gmail.com> wrote:
>>
>> > I switched my dev on this branch, so my .plan:
>> > 1 - new model with some tables required by Vertimus
>> > 2 - adapt my kid layout to Genshi (for Fedora and GNOME)
>> > 3 - integrate the business logic of Vertimus in Transifex.
>> >
>> > I'm going to push my patches to you at each step.
>>
>> This is good news, having a common codebase and roadmap from now on.
>>
>> You might also want to take a look at a doc we put together with a
>> proposed workflow for such changes [1]. Do we have any featureset and
>> plan for bullet 3, just to make sure we don't have duplicated work?
>
> The essential part of bullet 3 is a design pattern "State" around the class
> Module.
> I begin to rewrite this part in Python on my Launchpad branch.
>
> I've just take an hour to work on the bullet 1, I'm about to find stupid my
> model tomorrow ;) but before that, you can take look at the new model
> (attached SVG file).
Concerning UI/Docs: Since we're changing a lot of stuff in parallel
and quickly, I suggest to progress the work gradually. Here are some
milestones following this idea:
1. Stats show up (with random data)
2. Static POT support: Stats are populated from POs with static POTs
(majority of projects)
3. Basic Intltool support: Modules using intltool-update work too
(add a field "extraction-method" in modules choosing either static or
intltool support).
4. Full intltool support might need more models and methods.
5. Docs support: extraction from xml files as well.
Most of this work already exists in update-stats.py, which needs to be
cleaned and features added gradually in Tx.
-d
Stéphane Raimbault
Concerning UI/Docs: Since we're changing a lot of stuff in parallel
and quickly, I suggest to progress the work gradually. Here are some
milestones following this idea:
1. Stats show up (with random data)
2. Static POT support: Stats are populated from POs with static POTs
(majority of projects)
3. Basic Intltool support: Modules using intltool-update work too
(add a field "extraction-method" in modules choosing either static or
intltool support).
4. Full intltool support might need more models and methods.
5. Docs support: extraction from xml files as well.
Most of this work already exists in update-stats.py, which needs to be
cleaned and features added gradually in Tx.
Hi,
Who is working on this task (DL -> Tx)?
Where does 'update-stats.py' come from (from DL or Tx)?
I've written a script named 'update-stats.py' too (the script has nothing to do and the name conflict isn't voluntary :), this script (http://bazaar.launchpad.net/~sra/vertimus/trunk/files) parses the XML files of Damned-Lies (http://l10n.gnome.org/languages/fr/gnome-2-24.xml) and populate the database (with SA) so I can work on the Vertimus integration into Transifex w/o depend on any other work (I will respect the defined workflow, unit tests and so on).
To work together we need to define a common model.py.
Ciao,
Asgeir Frimannsson
you can check this out by:
if you have a fedora-account
hg clone ssh://user...@fedorapeople.org/~asgeirf/public_html/transifex-lies
otherwise (very slow)
hg clone http-static://asgeirf.fedorapeople.org/transifex-lies
A short INSTALL/readme:
1) Same requirements as tx-devel branch (genshi, sqlalchemy), but I have had issues with sqllite some times, especially when importing and running the tg app at the same time, so i have mainly tested with mysql..
2) To see some example data, run e.g.
./import_data.py -c http://translate.fedoraproject.org/
(-c will recreate/clean the tables, -h for more options)
or
./import_data.py -c --modules=gnome-modules.xml.in http://l10n.gnome.org
(if gnome is your cup of tea)
if you have a local checkout of DL/Fedora-DL you can use the path rather than the URL.
Now, the UI needs very much more work, and so does pretty much everything else. But it demonstrates an architecture that e.g.:
1) Separates Project&Targets from Repositories, modules, branches
- A project can e.g. change repository between versions without affecting the view from a translation side
- A project could e.g. link to a wiki rather than a VCS
2) Has the concept of a 'Builder', which allows different project-types/layouts to work together (e.g. intltool, kde-style, fedora-style projects).
- A ResourceContainer (db table) links to a python Builder, and Builders can store extra information in the DB, e.g. a IntltoolBuilder would have a IntltoolResourceContainer.
3) A project can have multiple PO files
4) Has the concept of a Sandbox, with implementations for e.g. SVN, Git, CVS... Locking and comitting will be added here as well. (one of our SoC students will probably replace this with something smarter)
I hoped to get it in a bit better shape before confusing everyone, but I'll be away next week, and if it can be of use to you or anyone else, go for it :)
cheers,
asgeir
Dimitris Glezos
> I've been doing some work on the DL->TX migration on a different branch. It
> has the full DL data model in sqlalchemy.
>
> you can check this out by:
>
> if you have a fedora-account
>
> hg clone ssh://user...@fedorapeople.org/~asgeirf/public_html/transifex-lies
This is a good work in terms of migrating DL's functionality in Tx.
We're fairly unstable these days and I as I probably already
mentioned, I think we should aim in adding incremental patches in
mainline accompanied with test cases. So in order to progress in
statistics integration, I'd suggest to change the model gradually with
increasing functionality of the small bits and pieces together with
unit testing, doc, and UIs for each feature added. This will allow the
model to evolve in a more natural way.
As an example, create a feature around 'person', get feedback, test
it, integrate it, add support for it in the import script for DL, get
it in -devel. Other similar small features could be collections,
multiple builders, targets, "alive" locales (in tables instead of
grabbing them with os.dir) etc. I'm more optimistic about the success
of incremental makes-sense feature addition than "let's make DL
migration work right away".
Stabilizing the platform should be our #1 priority right now.
> 2) To see some example data, run e.g.
> ./import_data.py -c http://translate.fedoraproject.org/
> (-c will recreate/clean the tables, -h for more options)
Maybe having a text file in the branch with information on it,
install/test instructions and a rough roadmap would help out in
collaboration and getting more people to bring it in shape.
And, our motto again: Tests, tests, tests! :-)
Vincent Untz
>
> On Fri, Jun 20, 2008 at 11:30 AM, Asgeir Frimannsson <asg...@gmail.com> wrote:
> > I've been doing some work on the DL->TX migration on a different branch. It
> > has the full DL data model in sqlalchemy.
> >
> > you can check this out by:
> >
> > if you have a fedora-account
> >
> > hg clone ssh://user...@fedorapeople.org/~asgeirf/public_html/transifex-lies
>
> This is a good work in terms of migrating DL's functionality in Tx.
>
> We're fairly unstable these days and I as I probably already
> mentioned, I think we should aim in adding incremental patches in
> mainline accompanied with test cases. So in order to progress in
> statistics integration, I'd suggest to change the model gradually with
> increasing functionality of the small bits and pieces together with
> unit testing, doc, and UIs for each feature added. This will allow the
> model to evolve in a more natural way.
>
> As an example, create a feature around 'person', get feedback, test
> it, integrate it, add support for it in the import script for DL, get
> it in -devel. Other similar small features could be collections,
> multiple builders, targets, "alive" locales (in tables instead of
> grabbing them with os.dir) etc. I'm more optimistic about the success
> of incremental makes-sense feature addition than "let's make DL
> migration work right away".
>
> Stabilizing the platform should be our #1 priority right now.
So I'm looking at all this right now. I think I kind of agree with
Dimitris, but not for the same reasons: I'm not sure that everything in
DL is that useful (at least, for now).
Is anybody working on this right now? I'll probably do some stuff there,
but I don't want to duplicate work...
Vincent
--
Les gens heureux ne sont pas pressés.