On 6/7/06, Christian Rose <[EMAIL PROTECTED]> wrote:
Speaking of specifiers, a thing I wanted to mention is the following
type of messages:
#: ../src/LSRMain.py:179
#, python-format
msgid "A %s with name %s was removed from profile %s"
The second and third specifier should not be a problem here
Yagor, thanks very much for your reply. :)
On 06/06/2006, at 5:51 AM, Yavor Doganov wrote:
Clytie Siddall wrote:
I have a licensing question. How does such a statement affect
those of us who have already assigned our translation copyright to
the FSF (for example, translators who contribute t
On 6/7/06, Peter Parente <[EMAIL PROTECTED]> wrote:
I just noticed Christrian contributed a partial sv.po translation. Thanks!
One thing I should point out is that some of the strings in the
template have %s in them indicating the will be filled with some value
at run time. These %s must also ap
I just noticed Christrian contributed a partial sv.po translation. Thanks!
One thing I should point out is that some of the strings in the
template have %s in them indicating the will be filled with some value
at run time. These %s must also appear in the translated string
otherwise Python will t
Furthermore, I think it's safe to remove the en_US.po file from CVS --
in GNOME, we require the source messages to be in US English, so there
should be no need for an en_US.po anyway.
It's only there to test if our install process properly installs the
translation. As soon as the first real tran
Clytie Siddall wrote:
>
> I have a licensing question. How does such a statement affect
> those of us who have already assigned our translation copyright to
> the FSF (for example, translators who contribute to The Translation
> Project)?
This is not a problem, IMHO. The copyright assignm
On 6/2/06, Peter Parente <[EMAIL PROTECTED]> wrote:
> Your build tools shouldn't touch the po files -- in GNOME, the
> translators update their po files themselves using intltool-update.
> This reduces the likelyhood of CVS conflicts and the like when a
> translator might spend days or weeks upda
I have a licensing question. How does such a statement affect
those of us who have already assigned our translation copyright to
the FSF (for example, translators who contribute to The Translation
Project)?
Sigh is right. I have no idea because IANAL. I believe what we'd like
to do is to *ask*
On 02/06/2006, at 10:12 PM, Peter Parente wrote:
Not a problem. I did not know about intltool-update. I will take
advantage of that from now on.
We do not have a general copyright assignment procedure in the
GTP, so
AFAIUI technically the translations belong to the translator who
contribute
Your build tools shouldn't touch the po files -- in GNOME, the
translators update their po files themselves using intltool-update.
This reduces the likelyhood of CVS conflicts and the like when a
translator might spend days or weeks updating a translation. So it
would help if you could treat the p
On 6/1/06, Peter Parente <[EMAIL PROTECTED]> wrote:
Lucky day. intltool-update --pot works fine. In fact, it actually
appears to do a better job than pygettext. I was not aware of this
improvement.
Great!
We already know that msginit works to generate language specific files
and have our ins
Lucky day. intltool-update --pot works fine. In fact, it actually
appears to do a better job than pygettext. I was not aware of this
improvement.
We already know that msginit works to generate language specific files
and have our install process setup properly to build po's and install
them as mo
On Thu, 2006-06-01 at 13:57 -0400, Peter Parente wrote:
> > Extended fonts looks ugly, because the HTML is Latin1, while
> > the server is saying it is utf-8. Not good for an i18n page :-/
> >
> > It may be solved using recode or iconv.
> >
> > I'm ccing to Malcolm.
>
> Are you talking about the
On 6/1/06, Peter Parente <[EMAIL PROTECTED]> wrote:
Thanks for the info. We can definitely look at how well the standard
intltool-update --pot commands works as compared with pygettext.py. My
guess is that intltool misses Python multiline strings, but we don't
have any of those that are translata
Extended fonts looks ugly, because the HTML is Latin1, while
the server is saying it is utf-8. Not good for an i18n page :-/
It may be solved using recode or iconv.
I'm ccing to Malcolm.
Are you talking about the LSR wiki page which MoinMoin renders? Or the
i18n tutorial?
Pete
__
Thanks for the info. We can definitely look at how well the standard
intltool-update --pot commands works as compared with pygettext.py. My
guess is that intltool misses Python multiline strings, but we don't
have any of those that are translatable anyways.
If I get the standard tools working wit
On Thu, 2006-06-01 at 19:44 +0200, Christian Rose wrote:
> [...]
> I don't know if the following page can be of any help:
> http://www.gnome.org/~malcolm/i18n/
Extended fonts looks ugly, because the HTML is Latin1, while
the server is saying it is utf-8. Not good for an i18n page :-/
It may be s
On 6/1/06, Peter Parente <[EMAIL PROTECTED]> wrote:
We've recently imported a new project called Linux Screen Reader
(http://live.gnome.org/LSR) into cvs.gnome.org. The code is set up to
support internationalization using autotools. I was informed that
gnome.org has a team of translators that can
Hi,
We've recently imported a new project called Linux Screen Reader
(http://live.gnome.org/LSR) into cvs.gnome.org. The code is set up to
support internationalization using autotools. I was informed that
gnome.org has a team of translators that can provide localized strings
for any project on re
19 matches
Mail list logo
