I am obligated to have the translation files for my custom modules in a translations directory residing in each module's directory. It would be nice if they were detected in the defined translation file storage directory as well. For contributed modules and core, the translation files are correctly discovered in the defined translation file storage directory.

CommentFileSizeAuthor
#31 locale_extras.drush_.inc_.txt2.47 KBtangent
#19 l10n_update-custom-module-ignored-1430004-19.patch427 bytesTor Arne Thune
#18 l10n_update-custom-module-ignored-1430004-18.patch2.17 KBsutharsan
#16 l10n_update-custom-module-ignored-1430004-16.patch796 bytessutharsan
#15 AvailableUpdatesListsCustomModule.png25.64 KBTor Arne Thune
#11 copyright_block.tar_.gz1.39 KBTor Arne Thune

Comments

sutharsan’s picture

sutharsan commented
Category: bug » feature
Status: Active » Closed (won't fix)

A translations directory per module is no longer supported since drupal.org moved to git. Either use the common translations directory or setup your own translation server using the Localization Server module and configure the location of this server in the .info file of your custom module. See README.txt and l10n_update.api.php for info.

Tor Arne Thune’s picture

Tor Arne Thune commented
Status: Closed (won't fix) » Active

That's what I was trying to say. I am trying to move away from having the translation files in the module directory, but putting them in the defined (common) directory for translation files doesn't work. l10n_update doesn't find the files there for custom modules. l10n_update does, however, find the translation files in this directory for contributed modules and core, so I thought it was strange that it doesn't work the same for custom modules.

Tor Arne Thune’s picture

Tor Arne Thune commented
Title: Translation files for custom modules not discovered in defined storage directory for translation files » Translation files for custom modules not discovered in defined common storage directory for translation files
Category: feature » bug

The bug, basically:

I have a custom module in sites/all/modules/custom
When I place translation files for this module under sites/all/modules/custom/module/translations they are found by l10n_update and imported. But I want to avoid using this directory.
To avoid using this directory I try to place them under sites/all/translations, but they are not found by l10n_update.
sites/all/translations is the common storage directory I have defined for the Drupal installation and where all other translation files for contributed modules and Drupal core are found and imported.

Translation files are found and imported by l10n_update from sites/all/translations for all contributed modules, but not for my custom modules (that are also enabled for the site).

sutharsan’s picture

sutharsan commented
Status: Active » Postponed (maintainer needs more info)

Have you used the syntax as described in the README.txt? Note that this requires the custom module to have a version.
I was not aware that po files in module/translations were still processed. But that may be done by core.

Tor Arne Thune’s picture

Tor Arne Thune commented

Ah, I need to define a l10n server for custom modules? I thought it was enough to put the translation files in the defined common translations directory and l10n_update would find it there.
The custom module's info file:

name = Copyright block
description = "Creates a copyright block with copyright information."
version = "7.x-1.0"
core = 7.x
package = Customizations
dependencies[] = block
files[] = copyright_block.test
sutharsan’s picture

sutharsan commented

You can do one or the other. For this module a po file named copyright_block-7.x-1.0.fr.po (for French translation) in the common translation directory should do the trick. See the README.txt.

Tor Arne Thune’s picture

Tor Arne Thune commented

Yes, that's what I have:

torthu@localhost:/var/www/drupal7test/sites/all/translations$ ls -l
total 1596
-rw-rw-r-- 1 torthu     www-data  12963 2012-02-02 13:40 admin_menu-7.x-3.0-rc1.fr.po
-rw-rw-r-- 1 torthu     www-data    557 2012-02-02 15:39 apc-7.x-1.0-beta3.fr.po
-rw-rw-r-- 1 torthu     www-data  35111 2012-02-02 13:40 backup_migrate-7.x-2.2.fr.po
-rw-rw-r-- 1 torthu     www-data    653 2012-01-25 15:37 copyright_block-7.x-1.0.fr.po
-rw-rw-r-- 1 torthu     www-data    678 2012-01-25 15:37 copyright_block-7.x-1.0.nb.po
-rw-r--r-- 1 www-data   www-data  39060 2012-02-02 13:54 devel-7.x-1.2.fr.po
-rw-rw-r-- 1 torthu     www-data 705912 2012-02-02 13:40 drupal-7.10.fr.po
-rw-r--r-- 1 www-data   www-data 705819 2012-02-02 13:55 drupal-7.12.fr.po
-rw-rw-r-- 1 torthu     www-data  40294 2012-02-02 15:39 google_analytics-7.x-1.2.fr.po
-rw-rw-r-- 1 torthu     www-data    528 2012-02-02 13:40 honeypot-7.x-1.9.fr.po
-rw-rw-r-- 1 torthu     www-data  14763 2012-02-02 13:40 l10n_update-7.x-1.0-beta2.fr.po
-rw-rw-r-- 1 torthu     www-data   1185 2012-02-02 13:40 maxlength-7.x-3.0-beta1.fr.po
-rw-rw-r-- 1 torthu     www-data   1016 2012-02-02 15:39 memcache-7.x-1.0.fr.po
-rw-rw-r-- 1 torthu     www-data    774 2012-02-02 13:40 navigation404-7.x-1.0.fr.po
-rw-rw-r-- 1 torthu     www-data   4751 2012-02-02 13:40 smtp-7.x-1.0-beta1.fr.po
-rw-rw-r-- 1 torthu     www-data  16720 2012-02-02 13:40 wysiwyg-7.x-2.1.fr.po
-rw-rw-r-- 1 torthu     www-data   4342 2012-02-02 13:40 zen-7.x-3.1.fr.po

When I install and try to import translations for the enabled modules:

(...)
WD system: admin_menu module installed.
WD system: admin_menu module enabled.
WD system: admin_menu_toolbar module installed.
WD system: admin_menu_toolbar module enabled.
WD system: backup_migrate module installed.
WD system: backup_migrate module enabled.
(...)
WD system: copyright_block module installed.
WD system: copyright_block module enabled.
(...)
WD system: l10n_update module installed.
WD system: l10n_update module enabled.
(...)
WD system: honeypot module installed.
WD system: honeypot module enabled.
WD system: maxlength module installed.
WD system: maxlength module enabled.
WD system: navigation404 module installed.
WD system: navigation404 module enabled.
WD system: smtp module installed.
WD system: smtp module enabled.
WD system: wysiwyg module installed.
WD system: wysiwyg module enabled.
(...)

The translation was successfully imported. There are 48 newly created translated strings, 29 strings were updated and 0 strings were removed.
Imported translation file sites/all/translations/admin_menu-7.x-3.0-rc1.fr.po.
The translation was successfully imported. There are 309 newly created translated strings, 30 strings were updated and 0 strings were removed.
Imported translation file sites/all/translations/backup_migrate-7.x-2.2.fr.po.
The translation was successfully imported. There are 4932 newly created translated strings, 77 strings were updated and 0 strings were removed.
2 chaînes de traduction ont été ignorées car elles contiennent du code HTML interdit.
Successfully downloaded and imported translation from http://ftp.drupal.org/files/translations/7.x/drupal/drupal-7.12.fr.po
The translation was successfully imported. There are 4933 newly created translated strings, 78 strings were updated and 0 strings were removed.
2 chaînes de traduction ont été ignorées car elles contiennent du code HTML interdit.
Imported translation file sites/all/translations/honeypot-7.x-1.9.fr.po.
The translation was successfully imported. There are 4993 newly created translated strings, 114 strings were updated and 0 strings were removed.
2 chaînes de traduction ont été ignorées car elles contiennent du code HTML interdit.
Imported translation file sites/all/translations/l10n_update-7.x-1.0-beta2.fr.po.
The translation was successfully imported. There are 4999 newly created translated strings, 116 strings were updated and 0 strings were removed.
2 chaînes de traduction ont été ignorées car elles contiennent du code HTML interdit.
Successfully downloaded and imported translation from http://ftp.drupal.org/files/translations/7.x/maxlength/maxlength-7.x-3.0-beta1.fr.po
The translation was successfully imported. There are 5001 newly created translated strings, 118 strings were updated and 0 strings were removed.
2 chaînes de traduction ont été ignorées car elles contiennent du code HTML interdit.
Imported translation file sites/all/translations/navigation404-7.x-1.0.fr.po.
The translation was successfully imported. There are 5044 newly created translated strings, 121 strings were updated and 0 strings were removed.
2 chaînes de traduction ont été ignorées car elles contiennent du code HTML interdit.
Imported translation file sites/all/translations/smtp-7.x-1.0-beta1.fr.po.
The translation was successfully imported. There are 5202 newly created translated strings, 152 strings were updated and 0 strings were removed.
3 chaînes de traduction ont été ignorées car elles contiennent du code HTML interdit.
Imported translation file sites/all/translations/wysiwyg-7.x-2.1.fr.po.
The translation was successfully imported. There are 5227 newly created translated strings, 169 strings were updated and 0 strings were removed.
3 chaînes de traduction ont été ignorées car elles contiennent du code HTML interdit.
Successfully downloaded and imported translation from http://ftp.drupal.org/files/translations/7.x/zen/zen-7.x-3.1.fr.po
Un fichier de traduction a été importé pour le module activé.
Traductions importées avec succès.
sutharsan’s picture

sutharsan commented

Can you try again with the latest dev version. I think you're not using the latest.

Tor Arne Thune’s picture

Tor Arne Thune commented

Sure.

torthu@localhost:/var/www/drupal7test$ drush dl -l drupal7test.local l10n_update-1.x-dev
Install location /var/www/drupal7test/sites/all/modules/l10n_update already exists. Do you want to overwrite it? (y/n): y
Project l10n_update (7.x-1.x-dev) downloaded to /var/www/drupal7test/sites/all/modules/l10n_update.

When I install and try to import translations for the enabled modules:

(...)
WD system: admin_menu module installed.
WD system: admin_menu module enabled.
WD system: admin_menu_toolbar module installed.
WD system: admin_menu_toolbar module enabled.
WD system: backup_migrate module installed.
WD system: backup_migrate module enabled.
(...)
WD system: copyright_block module installed.
WD system: copyright_block module enabled.
(...)
WD system: l10n_update module installed.
WD system: l10n_update module enabled.
(...)
WD system: honeypot module installed.
WD system: honeypot module enabled.
WD system: maxlength module installed.
WD system: maxlength module enabled.
WD system: navigation404 module installed.
WD system: navigation404 module enabled.
WD system: smtp module installed.
WD system: smtp module enabled.
WD system: wysiwyg module installed.
WD system: wysiwyg module enabled.
(...)

WD locale: Disallowed HTML detected. String not imported: Définit la CSS à utiliser dans la zone de l'éditeur.Utiliser la CSS du thème - charge les feuilles de style depuis le thème courantDéfinir la CSS - saisissez le chemin des fichiers des feuilles de style ci-desousCSS par défaut de l'éditeur - utilise les feuilles de style par défaut de l'éditeur.
WD locale: 1 disallowed HTML string(s) in sites/all/translations/wysiwyg-7.x-2.1.fr.po
WD locale: Disallowed HTML detected. String not imported: Le module Profil permet aux administrateurs du site de définir des champs personnalisés (tels que pays, nom, prénom, ou âge) pour les profils utilisateur, qui sont ensuite affichés dans la section 
WD locale: Disallowed HTML detected. String not imported: Le module RDF enrichit votre contenu avec des métadonnées permettant à d'autres applications (par exemple les moteurs de recherche, les agrégateurs, etc.) de mieux comprendre ses relations et attributs. Cette information enrichie sémantiquement et lisible par des systèmes, produite par les sites Drupal utilise la spécification RDFa qui permet aux données RDF d'être incluses dans le balisage HTML. D'autres modules peuvent définir des liens entre leurs données et des termes RDF, le module RDF rend alors ces données RDF disponible pour le thème. Les modules de base de Drupal définissent des liens RDF pour leurs modèles de données, et les thèmes de base génèrent ces métadonnées RDF ainsi que les informations lisibles visuellement par l'homme. Pour plus d'informations, consultez le manuel en ligne pour le module RDF.
WD locale: 2 disallowed HTML string(s) in sites/all/translations/drupal-7.12.fr.po
WD locale: 2 disallowed HTML string(s) in sites/all/translations/zen-7.x-3.1.fr.po

I can see in the watchdog table (and by looking at the site UI) that all modules have been translated (except for dev version of l10n_update of course) except the custom module copyright_block.

sutharsan’s picture

sutharsan commented

I can't reproduce this, manually (Update translation/Refresh information) via the Translation Update page nor using Drush. Or when enabling the module via drush. In all situations the file is detected and imported.

You have to debug the code to find the problem. Some suggestions:

  • $filename in l10n_update_source_check_file() contains the file name being looked for.
  • In l10n_update_source_build() this file name is composed based on information in $project.
Tor Arne Thune’s picture

Tor Arne Thune commented
StatusFileSize
new copyright_block.tar_.gz1.39 KB

These are the exact steps I use to reproduce the bug:

git clone --branch 7.x http://git.drupal.org/project/drupal.git drupal7x
cd drupal7x
git checkout 7.12
mysqladmin -u root -p create drupal7x
mysql -u root -p -e "GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON drupal7x.* TO 'drupal7x'@'localhost' IDENTIFIED BY 'password';"
mkdir -m 777 sites/default/files
drush si standard --db-url="mysql://drupal7x:password@localhost/drupal7x" --locale=en --site-name="Drupal 7 Git clone" -v
drush dl l10n_update-1.x-dev
wget -P sites/all/modules http://drupal.org/files/copyright_block.tar_.gz
tar xvzC sites/all/modules -f sites/all/modules/copyright_block.tar_.gz
drush en l10n_update copyright_block
mkdir -m 2770 sites/all/translations
sudo chgrp www-data sites/all/translations
mv sites/all/modules/copyright_block-7.x-1.0.fr.po sites/all/translations
drush vset l10n_update_download_store "sites/all/translations"
drush vset l10n_update_check_mode 3
Added the French language via the admin UI at http://drupal7x.local/admin/config/regional/language.

Result:

The language French has been created and can now be used. More information is available on the help screen.
One project updated: drupal.
French translation strings added: 4667, updated: 0, deleted: 0.
Warning message 2 translation strings were skipped because they contain disallowed HTML. See Recent log messages for details.
sutharsan’s picture

sutharsan commented
Title: Translation files for custom modules not discovered in defined common storage directory for translation files » Custom modules are ignored
Status: Postponed (maintainer needs more info) » Needs work

Ok, lets call it an undocumented feature ;) l10n_update ignores modules that don't have a project definition in the info file. All d.o files have one and have translation files available at l.d.o. Unreleased modules have none, custom modules either. And usually these don't have translation files associated. Add project = copyright_block to the info-file and it will be processed.

Note @self: Need to update documentation with this.

Tor Arne Thune’s picture

Tor Arne Thune commented

Ahh, that did the trick. Thanks for looking into this. I would not have guessed to add this line. Now I can move my translation files for custom modules to the common translation directory and be more ready for Drupal 8. One translation directory to rule them all.

sutharsan’s picture

sutharsan commented

Instead of 'project = xyz' I was thinking of something like 'l10n-update-source = local'.

Tor Arne Thune’s picture

Tor Arne Thune commented
StatusFileSize
new AvailableUpdatesListsCustomModule.png25.64 KB

I have discovered an unfortunate side-effect of having 'project = ...' in the info file for custom modules. With this line, Drupal will search for updates to the module on Drupal.org, just as with contributed modules. The result is that if the custom module has the same name as a project on Drupal.org, Drupal will propose updates to the module if they exist for the contributed module with the same name.

sutharsan’s picture

sutharsan commented
Status: Needs work » Needs review
StatusFileSize
new l10n_update-custom-module-ignored-1430004-16.patch796 bytes

Is is my practice to prefix custom modules with the project or customer name (abbreviation). But that's just a side node and not meant to solve the case.
This attached patch requires an entry in the .info file like:

l10n project = mycustom

I'm not sure yet if a change in the info file is the best way. The alternative is this hook, which is not very elegant either.

function mycustom_l10n_update_projects_alter(&$projects) {
  $projects['mycustom'] = array(
    'name' => 'My custom module',
    'project' => 'mycustom',
    'core' => "7.x",
    'version' => "7.x-1.0",
    'project_type' => 'module',
    'info' => array(
      'l10n server' => 'example.com',
      'l10n url' => 'http://example.com/files/translations/l10n_server.xml',
      'l10n path' => 'http://example.com/files/translations/%core/%project/%project-%release.%language.po',
    ),
  );
}
Tor Arne Thune’s picture

Tor Arne Thune commented

I must say I prefer the added property in the info file. My motivation for not prefixing the custom module name was that I wanted to create a common custom module that could be used across all projects I have, as I have all projects in one multi-site installation.
Adding the 'l10n project' property to the info files of custom modules that have translation files would be a fairly painless requirement for translation of custom modules. As long as it is documented that this is a requirement for the translation of custom modules, I don't think it would cause problems. As I've understood, translating custom modules is not a very common task, anyway.

sutharsan’s picture

sutharsan commented
Category: bug » feature
StatusFileSize
new l10n_update-custom-module-ignored-1430004-18.patch2.17 KB

Documentation added.
If more people support this patch, it will be added to the module.

Tor Arne Thune’s picture

Tor Arne Thune commented
StatusFileSize
new l10n_update-custom-module-ignored-1430004-19.patch427 bytes

How about this: Use the file name of the info file when the the project name can't be guessed by info file properties.
This would avoid having to add a l10n_update-specific property to the info file of custom modules.

The core Update module didn't do this in their update_get_project_name function because it wouldn't make sense to search for updates to custom modules (modules without a project property defined) on Drupal.org. For l10n_update it would make more sense, as l10n_update has the option of discovering translation files in a locale storage location.

tangent’s picture

tangent commented

I need similar functionality. It isn't clear if the "import" provided here is one time or if modifications to local po files are reloaded after the first time. I needed the ability to reload translations for custom modules and themes so I made my own module (for D6) with a drush command to support this. I will investigate further if l10n_update for D6 supports my requirements.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

It should definitely support it, no custom module required.

tangent’s picture

tangent commented

I've read the README.txt (6.x-1.x branch) and it doesn't mention local po files but only alternative update servers.

I currently host my custom component translations in /sites/all/modules/custom/module/translations or /sites/all/themes/theme/translations and found that l10n_update doesn't do anything with these. I've tried placing a po file in /sites/all/translations and using the drush command to update again but it was not found there either.

When you say "it should support it" do you mean now or at some future stage? What am I doing wrong if it's supported? Do I need to add a "l10n path" in the info file or something? That seems rather clunky.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

@tangent: have you set up your info file as discussed above for your custom module?

tangent’s picture

tangent commented

It is not obvious, based on the README file, that any change needs to be made to the info file for local po files. What should be added? Something like the following? Are relative paths supported? Absolute paths would be a big issue for testing in different environments.

l10n path = /sites/all/translations/module.po

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

@tangent: once again, have you read the comments above? Specifically #12?

tangent’s picture

tangent commented

Yes, the module info has a project line. It doesn't show up on the update page though.

I discovered that the update settings were set to "remote only" though so I changed that to local and remote but still no joy.

Tor Arne Thune’s picture

Tor Arne Thune commented

#12 has some unwanted side-effects if the custom module name is the same as a project on Drupal.org, as the Update module would try to find updates for the custom module, on Drupal.org. I think your best bet would be to apply Sutharsan's patch in #18 and adding l10n project = your_custom_module to the .info file of your custom module. This will allow l10n_update to find translation files for your custom module in the specified translations directory (usually sites/all/translations).

sutharsan’s picture

sutharsan commented

@tangent, This issue is about 7.x. But in 6.x this problem exists too. Patch in #18 is for 7.x. We should first agree on what a good solution is. In any case there will only be one translations directory for all (contib modules, contrib themes, custom modules, profiles, etc.).

tangent’s picture

tangent commented

@Sutharsan, thanks for the reminder about the version. I've tried the patch, with a manual edit, and it didn't have any effect that I can see. I've added the "l10n project" line to my info but the module still does not appear in the update page (admin/build/translate/update). I added a dpm() statement at the top of the _l10n_update_project_info_list() function but there is no output on the update page so I don't know what to make of that.

My current solution, a module based on l10n, works well for me because of my use case. All of the translations for our site are in code because that's easier to deploy and manage. I can "reload" translations with my module independently of updating remote translations. It almost seems like 2 different use cases to me but only because community translations for contrib modules are less urgent and local translations for custom modules are critical. The site is a fully bilingual goverment website by the way.

tangent’s picture

tangent commented

Ok, I discovered that I have to use "Refresh information" to get to that code block modified by the patch and my custom module is appearing in the list now. Updating works once but modifications to the po file do not show up as updated in the list. In the module info file the version is set to "6.x-1.x-dev" but presumably it uses the version to know if it should check for an update? What should we use for a version for custom modules so that l10n_update knows to check for changes? I have not bothered with module/theme versions before and I would rather not start.

tangent’s picture

tangent commented
StatusFileSize
new locale_extras.drush_.inc_.txt2.47 KB

Can I suggest adding a new drush command "l10n-reload" to force updating translations from local files only and leave the "l10n-update" to update remote translations? That's what my module does (the l10n-reload command). I'll attach my modules drush.inc file for review or inclusion.

sutharsan’s picture

sutharsan commented

@tangent, please create a new issue for this. The issue will get closed when the original problem is fixed and your suggestion may get lost. I'm not sure it this is the right solution for the problem. 1. Consider extending the drush command l10n-update with options to update individual projects and to force using local files. 2. Is the local module not updated due to caching? Checking for updates is expensive, therefore a minimum cache life time of one hour is used. A day of week life time is used depending on you settings. 3. The file time stamp is used to determine the change date.

sutharsan’s picture

sutharsan commented

@Tor Arne Thune, your #19 patch causes all modules which are no project to show up on the Translation Update page. Try the patch and you will see :)

I see two directions:
A flag in the .info file to indicate the module has a local translation file
An alter hook with which the module makes itself known (after being ignored by _l10n_update_project_info_list().

http://drupal.org/node/1329410 touches the same case for Drupal 8

SuleymanK’s picture

SuleymanK commented

#18 works fine. I needed this to translate features generated code. Thanks.

trickfun’s picture

trickfun commented

I have the same problem with the new multilanguage version of my project www.riparotto.com
the .po file of my custom module is imported but no translation is done
No problems loading the po file from the interface, I upload the file and the translation is ok

configuration:

drupal 7.15
l10n_update 7.x-1.0-beta3+1-dev (2012-Feb-10)
same problem with 7.x-1.0-beta3

my ripa_user.info file:

project = ripa_user
name = Riparotto User
description = Provides custom user information.
core = 7.x
version = "7.x-1.0-dev"
package = "Riparotto Core"

dependencies[] = ripa_core
dependencies[] = ripa_js

drush log:

Fetching update information for all projects / all languages.        [status]
Found 1 projects to update.                                          [status]
Updating translation.                                                [status]
Downloading and importing files.                                     [status]
Imported: ripa_user-7.x-1.0-dev.it.po.                               [ok]
Imported: ripa_user-7.x-1.0-dev.it.po.                               [ok]
One project updated: ripa_user.                                      [status]
Italian translation strings added: 0, updated: 13, deleted: 14.

process deletes 14 string and no translation is done.
why?

wusel’s picture

wusel commented
Category: feature » bug

I use:
D7.17 in German
Localization update 7.x-1.0-beta3+3-dev

There are three typos in the file "l10n_update.inc" in the new part of function l10n_update_http_check:
please change $uri) to $url) (lines 275, 278 and 281). This is why I have changed the Category to bug report. Please feel free to re-change.

After that I have installed and enabled http://drupal.org/node/1285276 (Import new users and their Profile2 fields from one CSV file) with the file "sites/all/modules/a_wusel_migration/translations/a_wusel_migration-7.x-1.1.de.po" and added the line
project = A Wusel Migration
in the .info file.
Now Localization update cannot find the language file.

Then I have added a line with the correct "l10n path = <path>"-line in the .info file (path beginns with "http://"). Now I get the error "HTTP error 403 occurred when trying to check <path>".
I think, the ".htaccess"-file in the root of the drupal-server stops this path because the .po files are stopped:

# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$">
Order allow,deny
</FilesMatch>

If I delete "po|" in the ".htaccess"-file in the root of the drupal-server, Localization update finds the .po file.

I think, if the "l10n path" is the same server as our drupal-server, we have to catch the .po files directly.

Wusel

sutharsan’s picture

sutharsan commented

For custom module you need to put the po file in the translations directory with file name matching the pattern: [project name]-[version].[language code].po
Translations directory set at: admin/config/regional/language/update. Project name should not contain spaces.

Back to feature request. The bug wusel reported is already fixed.

wusel’s picture

wusel commented
Category: bug » feature

I agree to #14 and #15.

From "Writing module .info files (Drupal 7.x)" (http://drupal.org/node/542202):

project (Discouraged, packaging use only)
Module maintainers should not use this at all. The packaging script on drupal.org will automatically place a string here to identify what project the module came from. This is primarily for the Update status module, so that Drupal installations can monitor versions of installed packages and notify administrators when new versions are available.

#38:
Many project names have spaces. My link in #36 too. Sorry.

To improve this great module, it would be nice to have a local solution. Something like

l10n-update-source = local

Thank you very much.

Wusel

sutharsan’s picture

sutharsan commented

There are two kinds of module names. The system name and the human readable name. I refer to the first. If you define a 'project' in the info file, Update module will also attempt to check for update info at d.o.

For implementation of l10n_update in Drupal 8 we have chosen for two optional parameters in the .info file:

interface translation project = example_module
interface translation server pattern = http://example.com/files/translations/%core/%project/%project-%version.%language.po

For custom module with a local translation file you could do:

interface translation project = my_module
interface translation server pattern = sites/all/modules/custom/%project-%version.%language.po

or

interface translation project = my_module
interface translation server pattern = sites/all/modules/custom/my_module.%language.po

If time permits this will be backported to Localization Update module.

wusel’s picture

wusel commented

@Sutharsan:

An backport to D7 would be nice to test this for D7.

Thank you very much.

Wusel

frank ralf’s picture

frank ralf commented

@#4
When l10n Update is disabled core seem to still pick .po files from custom modules /translations subfolders when installing the module which IMHO is a desired behavior because it's a very maintainable solution for small projects with only a handful of translatable strings.

osopolar’s picture

osopolar
Primary language German
Location 🇩🇪 GER 🌐
commented
Status: Needs review » Reviewed & tested by the community

Patch in #18 works fine and seems to be a good solution (in terms of #28). I don't think that we need to wait for the backport from d8.
The option "interface translation server pattern" is by design defined as described in the README, it's not necessary to make it configurable. The option "interface translation project" in #18 is called l10n project, which seems to be fine, because its the modules namespace.

sutharsan’s picture

sutharsan commented
Issue summary: View changes
Status: Reviewed & tested by the community » Closed (won't fix)

The 8.x code has been backported and is available as 7.x-2.x release. The .info file strings used in 7.x-2.x are different from the ones suggested in #18. It will be bad development experience if we introduce a new feature in 7.x-1.x which we know will break when migrating to 7.x-2.x or 8.x. Automatic migration from 1.x to 2.x is not possible for this kind of strings in the .info file. In my view it is best to no introduce this in 7.x-1.x and therefore I will close the issue. Feel free to disagree and to reopen the issue to continue the discussion.