On 05/12/13 15:51, Saint Germain wrote:
On 5 December 2013 16:28, Gary Martin <[email protected]> wrote:
Here is the patch series giving the french translation:
https://bitbucket.org/saintgermain/bloodhound-mq/commits/branch/t694_bh_i18n
However I put it on top of the previous i18n patch, it may not be what
Olemis wanted ?
Good!
I just moved the patch to t694/ folder. Please update from my patch
queue
repos
;)
However, I am writing as I have been trying to play with the patches from
the t694_bh_i18n branch. I may just be being a little too naive about how
to
apply the changes but I note a number of import errors from attempting
this.
They are certainly not hugely difficult to fix if they really do exist of
course. Are there any quick instructions on how to test what you have so
far?
I haven't checked (yet) how Olemis integrated my patch, but if you use
my branch, then
it should work without doing anything.
I had also some import errors before, but I think I fixed them all.
Can you give me
an example of the import errors you have ?
It is probably my misunderstanding at how bitbucket/hg works then. I found
that I got two patches out of the repo rather than the full repository.
Obviously I haven't been trying hard enough!
Hehe, I had a similar discussion on the mailing-list on month ago about the
topic of creating a wiki page to explain how this mysterious
bitbucket/hg/MQ works.
It took me a while to really understand how it works (and I am still not sure).
The problem is that this is completely off the official contribution guidelines
for Trac/Bloodhound. Normally we should stick to SVN diff (or maybe
use Github pull request).
It doesn't strictly need to be a patch resulting from an svn diff
command, as long as the way to apply the patch(es) is discoverable!
Updating the ticket with the current set of patches might work well enough.
I will try to unofficially send a howto this week-end though (except
if Olemis post something before).
It may help others as well (I personnaly find this bitbucket/hq/MQ
very interesting).
I also have a question on Bloodhound translation: if we customize our
own bloodhound_theme.html template, and put it in the templates root
folder, how can we translate it after that ?
I honestly do not know what to say... Let's beter forward this question
to
trac-dev ml
Not sure I understand the problem you are seeking to solve there so I
won't
try to comment on that yet.
If you want customize Trac or Bloodhound for your website (change the
layout for instance)
then you have to define your own template (bloodhound_theme.html for
Bloodhound) which will
override the default template.
See http://trac.edgewall.org/wiki/TracInterfaceCustomization
However if you do that, and introduced a bunch of new sentences in the
new template, then you
have to find a way for them to be translated by Babel.
Currently it is not really possible, even if I have found a dirty
workaround (see trac-dev mailing-list).
Per site customisation tends to happen in the %ENV/templates directory if I
remember correctly. I would have thought that it would be desirable for
internationalization to effectively extend to such customisations when they
are needed. Of course, not all customisations will imply new translatable
content.
I also think that it is desirable and I undestand some work are
currently done in this
direction, but we are not there yet. So if you have new translatable
content in your
customized templates, then you either have to wait or use my dirty hack.
Best regards,
I still wonder if the pot and po file solution is considered easy enough
for a site admin to work with. I would have thought that some of the
more common customisation would be "item.label = something" definitions
in the ini files for menu labels. I should probably delve deeper into
Trac's discussions on these topics.
Cheers,
Gary
