i18n support as a requirement for user-visible applications in Ubuntu (was Re: Wubi status)

[Steve Langasek]

On Mon, Mar 02, 2009 at 11:29:47AM +0000, Evan Dandrea wrote:
> On Mon, Mar 2, 2009 at 11:03 AM, Colin Watson <cjwatson at ubuntu.com> wrote:
> > On Mon, Mar 02, 2009 at 10:42:53AM +0000, Evan Dandrea wrote:
> >> I'm not sure how official this is, it does not appear to be in the
> >> Ubuntu Policy package (Colin, should it be?  Shall I file a bug?),

> > I don't see how we can realistically make it a requirement for
> > everything, much though we might like to. There is lots of free software
> > out there that is useful without being sanely translatable at one level
> > or another (for example, Subversion sends messages over the network that
> > are displayed to its users but were not translatable for a long time,
> > and adding this was a Hard Upstream Problem).

> > I wouldn't object to it being required for new user-visible elements of
> > the standard Ubuntu desktop, or other things at a similar level. This
> > should be discussed on ubuntu-devel, though.

> I'd like to start a discussion around the topic of making i18n support
> a requirement for user-visible elements of the standard Ubuntu
> desktop, as Colin mentions.  This was apparently discussed at UDS, but
> I cannot find anything authoritative on the subject by searching
> through the wiki and Ubuntu policy documents.  If we really are going
> to do this, can we please codify it somewhere?

> Personally, I think it should only be a requirement at a date before
> UI Freeze that gives translators enough time to look over the new
> strings.  I don't see the need for the requirement being set for
> applications entering the archive regardless of where we are in the
> release schedule.  It may not always be advantageous to spend time on
> getting translation support right over other areas of application
> development, so we should not go further than we have to in order to
> accomplish having translated software in the final release.

I think it's reasonable to allow initial uploads of software without i18n
support even if we want a policy of not releasing with new user-visible
elements that can't be translated.  But in that case we need to be confident
that resources are available to get us the i18n support before we hit UI
freeze; we don't want to be stuck having to pull whole packages out of the
UI at that late state because we've failed the i18n requirements.

As an aside, I suspect it's generally easier to implement i18n support when
you're writing a program than to add i18n support after the fact, because
strings that are shown in the UI have to be marked in the source and there's
no reliable way to do this automatically (if there were, we wouldn't need
them marked...).

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org