-----BEGIN PGP SIGNED MESSAGE-----
Caroline Ford wrote:
> I've no idea where to send this, as it involves Rosetta I've sent it here.
> As the bug supervisor for tuxmath I received
> https://bugs.launchpad.net/bugs/227392. It seems that Ubuntu has
> allowed people to translate the package into languages it can't
> support. The version of the program in hardy doesn't have support for
> right-to-left languages (and maybe many non Latin alphabets). Despite
> this Ubuntu has translated the program into Hebrew, which Doesn't
Nothing wrong with this IMO. How should LP/Rosetta know what kind of
scripts a particular software can support?
And as you have correctly stated in the bug report, this bug won't be
fixed until a new version is uploaded. Also nothing wrong with that.
Besides, this bug wouldn't have been discovered if no one would have
translated that program into Hebrew and actually tried to use it in that
language. So, it's a good thing to know that there is a problem, don't
> There is a gsoc student working on localisation issues, and the
> current version in SVN is built with sdl-pango which should deal with
> this issue. However it's still a waste of time for someone to
> translate our program into a language we can't support.
How can a user know that unless he can read and interpret the sources
(and actually did so)?
In all recent Linux distributions, desktops can deal with almost any
kind of language and script and therefor it should be safe for a user to
assume that most (if not all) applications can support all kind of
languages and scripts. If it turns out that an application cannot deal
with that, then it's a bug in that application and should be fixed.
> The lead developer was surprised that Ubuntu has a Hebrew translation.
> Like many upstreams they have no idea that Ubuntu translates packages
> itself, and doesn't send the translations upstream.
well, the issue that we don't send the translations upstream is indeed
something we work on to improve. However, we don't have any solution
ready yet, because that is mainly a logistic problem... we would need to
keep track of all upstream bug contacts for each package. Unless this
information is stored and maintained (!) in the package itself in an
easy to parse format, so that such kind of bugs can be submitted
automatically by script, I don't see any practical way to solve this
issue any time soon.
Suggestions for this are welcome, of course.
> I'm going to send him the new language po files, how we deal with the
> difference between po files for languages we both have is a common and
> recurrent problem that I personally don't have a workflow for.
Currently we give user contributed translation a higher priority IIRC,
but it can be overridden with the upstream version, if the translation
team feels the upstream version is better.
IMHO this is up to upstream how to handle this situation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
launchpad-users mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users