export per module

How would you identify files belonging to a submodule?

If a submodule (.info, .module) in a subdirectory, then it's a good assume to think that it's a distinct module packaged as a bundle.

Well, look at CCK 5.x, there are files like content_admin.inc, content_crud.inc etc. Also, all submodules are in the same directory. How do you tell what modules these belong to? This was made better in CCK 6.x thankfully. Compare http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/cck/?pathre... to http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/cck/?pathre...

However, even modules like Views 2 for Drupal 6 have submodules in the same folder: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/views/?path... How do you tell which subsequent include files are for views_ui.module or views.module? They are in shared subfolders!

Of course when modules exist in subfolders, translations should be exported into the relevant subfolders if they are not done already (I think they are done that way, but don't have time to test now. Please prove me wrong, if this is not the case.) However, in lots of cases, this is just not possible due to the unfriendly structure of the module's file layout.

All .module (or .info) files are submodules. Does not matter if it is in subdirectory or not. Open the admin/reports/updates page and see the "Includes" line. Those are all submodules as I see it.

How would you identify files belonging to a submodule?

That's a pretty good question.

Let's see the possible file naming conventions (or how developers name their files):
modulename.module
modulename.install
modulename.admin.inc
modulename.pages.inc
modulename.views.inc
modulename.something.inc

and some weird (which probably should be fixed)
modulename_admin.inc

and the views handler, style, plugin files
modulename_handler_..
modulename_plugin_..

test files
modulename.test

js files
modulename.js
modulename_admin.js
something.js

is there any other? templates maybe?

****

so the submodule detection algorithm could be:
get the list of all submodules, mark the main module
order them by the length of modulename, move the main module to the last position
test the file name

one great example:
1. context_ui_contrib
2. context_prefix
3. context_ui
4. context (or any other)

now test if the file name starts with these strings. test in the given order.

As I've said, while we can make up some rules which work in generic cases, even Views 2 is a good counter example. You have two modules in the same folder and then several include files in subdirectories named after neither of the modules. Now which of those include files belong to which of the modules? I mean, if the most mainstream modules don't make this easy, how do we expect to reliably be able to detect submodules with their assorted files?

As I see all those include files fall under the main views module (and the proposed algorithm tells the same), I can't find an include file which is for the views UI module only.

Well, includes/tabs.inc or includes/admin.inc is included form views_ui.module but not from views.module. While views.module includes includes/ajax.inc, which views_ui.module does not include. How does your algorithm get to these conclusions?

I should give up, but not yet, because submodule detection is a really must feature.

so, I will try to analyze the files
includes/tabs.inc is a general visual element, could be in core, that's why I would not tie it to views UI (there is no views_ui specific code in it)

includes/admin.inc. oh, f*. that file is wrongly named for sure. Every function name starts with views_ui. Will try to convince Merlin to rename that file.

the third file is ok, it belongs to the views module

so the official answer on admin.inc #329517: Rename admin.inc file to views_ui.admin.inc

I cannot guarantee that admin.inc will only ever be used by views_ui

so the file belongs to views module.

Suppose better to make tagable suggestions so it makes additional dimension for freetaggin suggestion

It possible brings "social translations" if every user can produce it's own branch (tag, term)

just need provide hook_l10n_api ($op, $data)

$op is CRUD
$data is object (suggestion, lang, project, version, taxonomy)

Any ideas?

@andypost: I don't get how this relates to exporting per submodule.

submodule consists of files (l10n_community_file) and every module and submodule can share some files

so before d7 which knows exactly all it's files from .info there's posibility to make tags (maybe flags) to mark set of files

Suppose it make another dimention to use not only to export submodules but for example set of files which used on supported website (it makes life easy)

it is not 100% in D7 either. you can easily create and include files which are not listed in module's .info file..

the best solution is to not create large module packages, so module translations can be exported simply as "all in one"

We have submodules in D7 now (see modules/field/modules). "The best solution is to not create large module packages" is NOT a best or good solution at all. What we should be doing is encouraging module authors to use a standard directory system (something like not have more than one module per directory, using mymodule/includes, etc).