Trac internationalization
Nicolas Ternisien
As you can see in my previous mail, my goal was too update the Trac
french translation to the current trunk/ version of Trac. However the
manner that this translation is done is really ugly, because it's a
full copy of the Trac project, that replace each English string by
French ones.
My first question is : What about putting TracFrenchTranslation
directly in Trac SVN, in a branch for example. With this, it will be
really easier to apply trunk/ patches using svn merge. Of course, this
will need to remove the current project in trac-hacks.org, but it
should not be a problem if French translation is located in main Trac
project.
My second question is : What do you need and what do you plan for
internationalization and localization of Trac ? Do you plan to use
python gettext or something similar ? What do you think about creating
a subdirectory by language in wiki-default folder, and ask an
additional question for the language choosing in trac-admin initenv
action ? If you can give me more details about your plan, I will be
really happy to help you.
Cheers
Nicolas Ternisien
Jeroen Ruigrok/asmodai
>My first question is : What about putting TracFrenchTranslation
>directly in Trac SVN, in a branch for example. With this, it will be
>really easier to apply trunk/ patches using svn merge. Of course, this
>will need to remove the current project in trac-hacks.org, but it
>should not be a problem if French translation is located in main Trac
>project.
Having done my share of various i18n projects and translations I want to point
out the following:
1) Adding them to the main project means you would need someone active for
every language you add in this manner, simply because if the main authors
change things around these changes need to be reflected in the
translations. If they are not you get either outdated texts, English
default texts. Both look bad.
2) I am not entirely sure how much the source tree would grow if you add every
translation to the tree. The tarballs aren't a problem since you will
effectively compress them using gzip or bzip2 anyway and text compresses
perfectly.
3) Putting the translations in the tree would typically encourage native
speakers or people with a sufficient proficiency level to work on these
texts. This as opposed to some external project.
Also you can leverage from typical l10n frameworks to minimize duplication
and only focus on the texts.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/
Time will tell everything - given time...
Matt Good
Yes, the current translations are hard to maintain. Trac 0.11 will
support i18n properly through gettext. The porting of Trac's templates
to Genshi will help since it will allow the templates to be translated
on the fly with a filter. I don't know if the Wiki has been discussed
yet. Providing several copies of the default pages in folders may be
an option.
I'm sure this will start getting more discussion once 0.10 is done and
0.11 development becomes more active. So, stay on the list since we
can certainly use some help with the translations.
-- Matt Good
Nicolas Ternisien
project. It should not be taking more than 10/15 hours, can be simply
implemented, and will solve the full source copy to translate Trac. I
am putting forward an additional work force (myself) to the project,
so it should not be a problem if the internationalization comes more
early than intended.
Of course, the code modification will be provided as a patch, so you
will be able to test it before apply it to trunk.
Cheers.
Nicolas Ternisien
Noah Kantrowitz
any work you were to do now wouldn't be able to be used (at least not
easily) after that. Once Genshi gets integrated there should be an
actual framework to do translations.
--Noah
Christian Boos
> And would you be okay to let me doing internationalization of your
> project. It should not be taking more than 10/15 hours, can be simply
> implemented, and will solve the full source copy to translate Trac. I
> am putting forward an additional work force (myself) to the project,
> so it should not be a problem if the internationalization comes more
> early than intended.
>
> Of course, the code modification will be provided as a patch, so you
> will be able to test it before apply it to trunk.
>
Please no patch on trunk at this point... it's certainly a waste of
efforts, as we won't support i18n for 0.10.
Though this has not yet formally discussed/decided, there seems to be
general consensus that 0.11 should start with the merge of the Genshi
branch. There's still the report module that's left to be migrated, but
beyond that, the migration is pretty much complete and works fairly well.
The "problem" is that during the migration, not only the templates did
change completely, but also a lot of code in the controllers has
changed. All of this makes the merge process between 0.10/clearsilver
based code and sandbox/genshi based code a bit painful.
Sometimes I even wonder if it wouldn't make sense to rebase 0.10.1 also
on the genshi branch, as the feature set is pretty much the same, and it
will ease bug fix porting for the coming months. An alternative would be
to release 0.11 shortly after 0.10, more or less only with the switch to
Genshi (retargeting all 0.11 items to 0.12, hell who cares about the
numbers ;) ).
In any case, the risk would be to have to maintain 0.10/clearsilver for
one more year, with a trunk evolving to something radically different
from the 0.10/clearsilver codebase.
Adding i18n would probably have a similar impact in term of
mergeability, because of the "_()" calls that would be spread all over
the place, so I'd like to do that early, together with the Genshi merge
(just after).
Opinions?
-- Christian
Alec Thomas
> Sometimes I even wonder if it wouldn't make sense to rebase 0.10.1 also
> on the genshi branch, as the feature set is pretty much the same, and it
> will ease bug fix porting for the coming months. An alternative would be
> to release 0.11 shortly after 0.10, more or less only with the switch to
> Genshi (retargeting all 0.11 items to 0.12, hell who cares about the
> numbers ;) ).
This sounds like a good idea to me. Developers can start porting their
plugins sooner rather than later, and it will expedite the removal of
Clearsilver.
--
Evolution: Taking care of those too stupid to take care of themselves.
Emmanuel Blot
> french translation to the current trunk/ version of Trac. However the
> manner that this translation is done is really ugly,
Yeap, at the time the translation has been started, there was no other
way to do it.
As I18N/L10N had been "officially" planned for 0.12, I was waiting for
the new templating engine and I18N bricks to use a cleaner solution.
> My first question is : What about putting TracFrenchTranslation
> directly in Trac SVN, in a branch for example.
I don't think it is worth doing it until I18N bricks are ready: the
translation bits and pieces will be quite different by that time, so I
don't think it is worth polluting the main repository with this ugly
port.
BTW if you want svn write access to the TracFrenchTranslation subtree,
I think Alec can grant you the permission rights - I don't have enough
time to update this "project" on a regular basis, I have no problem
sharing access to the source tree.
Cheers,
Manu
Nicolas Ternisien
that want something too early ;-)
So, I am very pleased that you agree to let me maintain the
TracFrenchTranslation.
Can you create me the account "lastnico", and for the password, do you
use htpasswd2 command ? If this is the case, this is my encrypted
password "6Np5gaU6922F6"
Cheers.
Nicolas Ternisien.
Noah Kantrowitz
--Noah
Nicolas Ternisien
Is their an additional step or my account already has write access on
TracFrenchTranslation ?
Emmanuel Blot
> TracFrenchTranslation ?
Only Alec (the TracHacks admin) can change the permissions, AFAICT.
I sent him an email yesterday evening (you were in CC:), I havn't got
any news up to now, but I think we can give Alec some time to answer
;-). He'll probably notify you when things are set up. No idea whether
he uses htpasswd on his server (I don't).
Cheers,
Manu