Rob Weir wrote:
1) release new languages via lang packs only for now 2) release full installs, but for only these new languages
I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are "late" additions and that full installs will come with the next release.
Can we really skip the release process? PO files == source, right?
Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree).
Maybe a question for legal-discuss if we're not certain.
If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask.
How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer.
There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing.
In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)?
This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet).
Regards, Andrea.
