Could you be more
specific on the naming
convention for the NL zips for "Brazilian Portuguese", "Traditional
Chinese", and "Simplified Chinese"?
If the database contains string "Traditional Chinese", then yes, I'll
use that :-) The zips will be named whatever the language name in the
database is.
For output 1 and 2, do you really
want
to zip up all the NL plug-in fragments for all projects for one
language
into one big zip? The zip will be quite big! Well, if we divide them by
projects, we have 10 times more zips to manage :-(
I'm open to ideas. I could one per project. (That would be 90 zips
because there are 90 projects.) The main thing is that the solution
needs to be consistent and automated. We can't have one solution for
the Platform and one for CDT and one for Mylyn, etc - that's for the
projects themselves to assmelbe.
In Output 3, you proposed to create
one zip per plug-in, per version, per language. What about the NL
feature
containing these NL plug-in fragments? How should we zip them up?
I wasn't planning to create the NL features in option 3 because each
project team/distro team will want to gather the fragments in different
ways. For example, the Platform team has the SDK NL pack and the RCP NL
pack and so on. Web tools will want to do the same. So those teams can
take the output 3 fragments and put them together with features (just
listing the fragments) and distribute them via their download page. At
least that was my idea.
- Bjorn
|