I really like your idea of basic pack Vs full pack, as long as I don't consider the distribution complexity.

In the basic pack, I would indeed only provide 1 language (english or course) and core plugins. In the full pack, I would provide as many language as possible, adding 3 languages between 2.0.0 and 2.0.1 is not a problem at all. In the full pack, we add the a selection of most appreciated plugins to the core plugins.

Some plugins are part of the core. I mean they are core features and the plugin is only a way to add a feature.

We have a great plugin manager because it discusses with the Piwigo website extension manager. In the future I hope we will also add themes and language manager discussing with Piwigo website extension manager.

I have looked at other projects :

ZenPhoto  : 11 languages
Drupal    :  1 language (english)
WordPress :  1 language (english)
PhpBB     :  1 language (english)

Even if my sample is tiny, I would say that most of the distributed web applications are provided in english only. But I don't really like that, I do much prefer having many languages directly in the archive.

I propose that concerning 2.0.0, we keep the current set of plugins (even if I admit we provide too many interesting but not necessary plugins) and as many languages as possible. We will think for next branch which plugins to keep in the core.

Of course, I pushed too far the logic.

You are right.

We must include as Configuration / Menus we already have, a Configuration / Themes.
Just to make themes enable/disable.
And like Plugins upload new ones, update old ones, and delete some (except the default one).
The advantage is also to switch users who have a disabled/deleted theme to the default one.

Happy we will be.
8-)

PS: And a theme swapper.

Plugins: Process to manage them is correct. Ownership transfer is a problem.
1.7 example:
PicLens and Piclens are the same plugin with different sources and different managers. You couldn't use automatic upgrade but only automatic install.
Except that a centralized management is useful for searching news/updates.

Themes: Process will be the same.

Plugins and Themes may or may not be ready for localization. I mean you could have French or German or Russian hard coded. That a second level of problem.

Language availability is another problem. But It has nothing to do in this topic.

Back to the topic:

1 - Themes: I propose to externalize at least p0w0 and maybe wipi, and to distribute these theme in extensions.
In addition, we should:
- set Sylvia as default (done),
- keep clear and dark as simple basis, and samples of what themes mean for us.
- update user_infos table in upgrade process to switch all existing profiles from p0w0 or wipi to Sylvia.
- Focus: to produce a theme manager after Piwigo 2.0

2 - Plugins: AMM (Avanced Menu Manager) and STC (Swift Theme Creator) don't have to be distributed with Piwigo, does others must be?
With 1.7 plugins was the main new function, Plugin management wasn't there. It was normal to give sample.
Today, plugins management is there, so no samples are ever needed.
But with no pre-activated plugins, some webmaster would never use plugins (a bit afraid of that).
I recommend:
- to have at least those which are useful for debuging and/or learning (LocalFiles Editor, ...).
- at least LocalFiles Editor must be already active after migration or installation.

3 - Languages: Open another topic.

8-)

Ok,  Admin Advices actif after Installation process only. Upgrade will let it as is.

upgrade won't just force:
$conf['enable_plugins']=false;

Is that enough?
Am I wrong?

8-)