Re: [Gnash-dev] release criteria? Internationalization

[John Gilmore]

> 8. Finish internationalization support.

I would move internationalization to the "optional" pile.  Some of it
will be in the release, but I wouldn't make it a criterion for holding
up the release.  The main reason to get internationalization into this
release at all, is to let people know we care about it -- welcoming
them to come and help translate.  It will never be "finished" -- it's
a long term process.

In the upcoming release, I don't expect *any* translations to be
complete and accurate.  (Well, I could be surprised, since gnash has
so many multilingual developers already on board.)  But for this
release, I'm basically just trying to lay in the framework.  I'm
expecting the bulk of the translation work to happen AFTER the
release, in CVS, where it will benefit future releases.

strk said:
> I haven't looked at this, but would it mean translating all the
> ACTIONSCRIPT ERROR and MALFORMED SWF warnings ?

Yes.  There isn't much else to translate, except the documentation.

> I'm asking because those warnings change and augment very often.

Yes, and that's just fine.  The translation system (GNU gettext) is
very much oriented toward evolving, open source code.  It copes well
with the situation where some of the messages have been translated
into your particular language, and others haven't.  For translators,
it also automates the process of finding the untranslated new messages
quickly, so they don't have to waste a lot of time when updating the
translations for a language that hasn't been checked in a few months.

We *want* those warnings to change and augment all the time.  So don't
concern yourself at all with "making more work for translators"; just
improve the code to be the best you know how.

The translators will gradually catch up with the current state of
the code, depending how many people volunteer, what languages they
know, and how diligent they are about checking the CVS once in a while.

There's a pretty good manual written about the whole internationalization
and localization process here, from overview to gritty details:

  http://www.gnu.org/software/gettext/manual/gettext.html.gz

There are lots of international issues we haven't even started to
face, like localization of date/time formats, that will take time and
testing to work out.  We don't know what other flash players do about
this, and while we don't want to break existing movies, we do
eventually want to provide facilities that make it easy for authors of
flash movies to make their movies use local language, customs, and
culture.  In the same way that GNU gettext makes it easier to write a
C++ program that works well worldwide, we'll probably in the long run
want to add ActionScript facilities that enable flash developers to
easily internationalize their movies.  (If Adobe hasn't done so, we
may end up ahead of them -- then they can play catch-up.)  But this
year we aren't doing ANY of that.

        John