> 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 _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
