.pot file for translations
Frank Ralf - April 27, 2009 - 16:42
| Project: | Privatemsg |
| Version: | 7.x-1.x-dev |
| Component: | User interface |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
| Issue tags: | .pot file, template, translation |
Description
I created a .pot file from version 6.x-1.0-rc2 using the Translation template extractor (http://drupal.org/project/potx) which can be translated using a tool like Poedit (http://www.poedit.net).
The translation files should be copied to a yet to be created "translations" sub-folder in the module folder.
hth
Frank
| Attachment | Size |
|---|---|
| privatemsg.pot | 10.08 KB |
#1
Thanks, but please re-create the file for the -dev release, there were many many changes since rc2.
Edit: Also, I can see from your profile that you do have CVS access. You should be able to commit that file yourself, every translations directory is writable for all developers.
#2
Have just committed that file (http://drupal.org/node/293907#comment-1525810). Will re-create it for the dev release.
Frank
#3
You should create a pot (and po) per submodule, so that only translations that are actually used are loaded when you enable the module.
#4
Hi Sascha,
I thought about that but think one pot/po file per module is a better approach because that way it's easier to maintain a consistent translation across all sub-modules.
Doing so won't create any overhead IMO. Drupal loads all provided translations at install time into the locales_source and locales_target tables in the database. The t() and locale() (http://api.drupal.org/api/function/locale/6) functions do a just-in-time translation for all the strings on a loaded page and will retrieve the translated strings from the database tables if present. If not, those strings will be added to those tables.
So creating separate pot/po files for each sub-module would only save some space in the database and even that only if you never installed that sub-module. As the current pot file is only about 12 KB I think this effect is negligible.
So I would suggest sticking to one pot/po file.
Cheers,
Frank
#5
AFAIK it's common to use multiple files, a example:
./date/date_repeat/translations/date_repeat.pot./date/date_copy/translations/date_copy.pot
./date/date/translations/date.pot
./date/date_php4/translations/date_php4.pot
./date/date_popup/translations/date_popup.pot
./date/date_timezone/translations/date_timezone.pot
Same for CCK, FileField and many others.
#6
As I see this as a general issue I moved this discussion over to the Internationalization User Group (http://groups.drupal.org/node/21731).
Frank
#7
I feel that it is always a good idea to keep related items together, the whole point of breaking the private message functionality into sub-modules is to give options and ultimate flexibility to the users of privatemsg. On that same note i think translations are not exempt from the same approach. Users shouldn't need to clutter their DB with translations that do not need to be translated for various reasons.
#8
The attached patch does update the *.pot files and also splits them up per sub-module. The diff against privatemsg.pot is pretty much useless, though... :)
#9
Updated the patch, will commit this soon.
I used --mode=multiple and all strings that occur in multiple modules are part of privatemsg.pot.
#10
Commited, needs to be done for 7.x too
#11
Commited to 7.x. This will need another update short before the 1.0 release but is fixed for now.
#12
Updated to include the latest chance, the strings should now be fixed for the 1.0 release.
Note that this does also partly revert the change from http://drupal.org/cvs?commit=292344 since that commited merged all strings into a single file again.
I wil commit this to 6.x-1.x-dev now.