Installer.pot is not generated (properly)

The problem is a bit deeply rooted. In fact, l10n_server does not now about specific installer strings at all.

An obvious fix would be to add a flag to the source table, so we can flag installer strings and export as such. But then we should not export installer-exclusive strings for the runtime exports, so we would need a flag to indicate runtime-exclusive strings. Then we could merge these into one flag.

BUT, a string which is in the installer in one project is possibly used in another, but no in its installer. So we need to move this flag to the project level. And while we are at it, we need to version it based on project releases (D5 and D6 installer is quite different). So we should have flags on source strings based on a project release. This is either solvable with a dedicated table or a special file we record for each project release, let's say the "installer" file, with which we could look up all installer strings. This special file could link to strings, which are also "linked to" from other files. Those source strings only linked to the "installer" file in a specific release of a project are installer-exclusive.

We should first implement this on the input side, then on the output.

BTW I am concentrating on having the same export format as potx 6.x for core (ie. look into drupal-pot 6.x-rc2) first, and then to have proper installer translations. Any help is welcome in any of the issues! :)

Implemented this a better way. We need exact file and line information for installer strings as well, so having a special installer file would not cut it (as I imagined above). Actually, our string saving function gets information on the type of string being saved (runtime only, installer only, or both runtime and installer string), so we need to store that. But where do we store that? Of course on the file-line-string relation; in the line database table. So we know if an occurrence of a string is in the installer or in the runtime or both. Then on export, we collect all occurrences of the string, correct the flag (if we found one runtime only and one installer only, that becomes 'both'), and export the string in wherever it needs to live, depending on the flag.

My limited testing shows that this now creates something which looks like the expected installer.pot file (and it names it $langcode.po when using a language export). Please test and reopen this, if this it is not the case.

http://drupal.org/cvs?commit=96041
http://drupal.org/cvs?commit=96042

Note that a database update is required and you should empty your project, release, file, line and error tables, and rescan all files. Keep your source strings and translation tables intact, the rescanning will find them and use them, avoiding all duplication. Installer string information will only be available in the database after the database update and reparsing of projects.

The $langcode.po was not put in the right $po_folder, now also fixed. Thanks to Sutharsan's note on IRC.