Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
If you want to translate a specific module, you want to filter the strings that shows the Localization client module by the module you want to translate. For example, if you want to translate the Ubercart module, you want to only view its strings in the l10n_client interface.
The same way, you have to be able to export only the translation of this module separately.
This special workflow is to use l10n_client to translate modules to import to the localization server (l.d.o) later.
Comment | File | Size | Author |
---|---|---|---|
#15 | project-based-extract.patch | 15.36 KB | Gábor Hojtsy |
#13 | PotxProjectPicker.png | 103.71 KB | Gábor Hojtsy |
#13 | newpotxui.patch | 15.37 KB | Gábor Hojtsy |
#12 | newpotxui.patch | 6.34 KB | Gábor Hojtsy |
#11 | PotxUISuggestion.png | 195.64 KB | Gábor Hojtsy |
Comments
Comment #1
Gábor Hojtsy@rvilar: the potx module allows you to export .po files per module. The l10n_client (or Drupal for that matter) does not know which string comes from which module, and that is not possible to tell without data from potx. That data is not stored in the database, so your feature request in terms of filtering the l10n_client strings by module would need to have development in both potx and l10n_client. Not a trivial task I'd say.
In the meantime, you could still use potx to export .po files per module.
Comment #2
rvilar@Gábor Hojtsy: The real question is: Are you, the project maintainer, interested in this new feature? I can develop this new feature and modify the potx and the l10n_client modules if the comunity wants.
Comment #3
Gábor HojtsyOk, let's consider potx first. It would need database storage of the data and if you've tried, you probably noticed that it takes a lot of time to parse all of Drupal core and modules. It would also need support for project detection, something I believe there might be another issue. It should not only know that something belongs to uc_cart but also that it belongs to Ubercart to satisfy the localize.drupal.org use case.
I think this feature would be great, but (1) I question we can make the usability of it painless and (2) there seems to be multiple dependent issues we need to solve first (all of which would be great to solve).
Comment #4
rvilarOk, I would like to contribute to this project. Can you help me? What are the multiple dependent issues we need to solve first?
I've read the list of issues but I didn't find the related issues.
Comment #5
Gábor Hojtsy@rvilar: Huh, I did not find the existing issue either, but I remember we had an issue discussing potx to know the project for each file it is parsing. Basically the first task would be to relate the files to projects, so potx would know that views-admin.inc or bootstrap.inc belongs to different projects (and could name these projects). The update status module has code for this in Drupal 6 which might be reusable. Once we know the project, we can store the relation of strings to projects in our own database table and use that to export stuff per project (fulfilling half of your original plan). Then l10n_client can also depend on this data optionally and display only strings for one project or just provide a filter allowing you to do so interactively.
Comment #6
rvilarWorking in this issue
Comment #7
rvilarStop working for a while. I want to check other issues first, because it will be my first patch and I want to work in less complex job first. Afterward I will return to work in this issue.
Comment #8
Gábor HojtsyHere is a very rough start at project identification reusing most of the update module library code. We do need to copy and redefine one function, since we need to pretend all modules and themes are enabled for them to be processed by the update status code, so we get a list of them for extraction. This is obviously a very early stage of the code, but is there to help us get started.
Comment #9
Gábor HojtsyOk here is a more advanced patch which now makes potx dependent on update.module, implements tricks stolen from update_advanced module to include data for disabled modules and themes and present a much nicer list of projects to extract from.
Obviously we are getting the possibility to pick Drupal core itself for extraction and a much nicer project presentation but we loose the more fine grained extraction possibility that was possible with the uglier UI before (eg. you cannot extract submodules with this UI).
I've also worked more here to unify this export UI with the current export UI of the l10n_server, so we have very similar options here (see #637820: Simplify export screen, unify with packaging).
Note that none of the backend is updated yet, only the UI is there, so we can discuss that and then update the backend if there is consensus.
Comment #11
Gábor HojtsyFinally could upload an image of the patch:
Comment #12
Gábor HojtsyUpdated patch now comes with .info file altering code to identify projects which are not identified by update module (and not by cvs_deploy if that is installed). It merely uses the last item in the path to group modules/themes together into one project.
This has inevitable side effects in update module. Just as it makes all disabled modules to be checked for in update status, it also present update status with modules which are probably not available on drupal.org. We should find a way to tell update status that these projects are identified, but no update server should be used to check for them. Mark update server as NONE / NULL or something. Unfortunately, by looking at _update_get_fetch_url_base() and friends, it does not seem like this will be possible at all.
Patch still only includes the UI and does need improvement on the UI as well to be able to pick subprojects to not loose that functionality.
Comment #13
Gábor HojtsyWorked more on a useful UI. This is what I came up with. Allows to select subprojects again (which is possible before the patch), but has a way nicer layout then the fieldsets before the patch; identifies projects as much as possible and will allow for extraction of Drupal core itself.
@todo with this patch includes making the form actually work (the submission code is not yet updated to the new selectors). Also, update module drops its nice project data after an hour, after which our nice project names turn into ugly directory names for top level projects (not for submodules). We need to try and force update status to get us its data if possible, like visiting the update status screen does when the data is not available.
BTW opened an issue at #655210: The right way to reuse update.module functionality to figure out the right way to reuse update.module's project identification.
Comment #14
Gábor HojtsyAlso, adding in a sort for the subprojects at least would not hurt :)
Comment #15
Gábor HojtsyHere is a quick reroll of the above patch in preparation of a 6.x-3.1 release (which will not yet include this change due to how unfinished it is).
Comment #16
Gábor HojtsyThis is not 100% in the ldodomination realm, but we need the same code in l10n_client so I'm tagging as such.
Comment #17
Gábor Hojtsyl10n_update already got code like this, so not related to localized installs anymore. Anybody interested in this functionality?