Posted by Libra on January 9, 2012 at 8:31am
3 followers
Jump to:
| Project: | Localization server |
| Version: | 7.x-1.x-dev |
| Component: | Export |
| Category: | support request |
| Priority: | normal |
| Assigned: | lucascaro |
| Status: | postponed |
Issue Summary
Have a question about using own connectors to proccessing non-Drupal and non-Gettext files. Could not find anywhere information, how to implement in own connector not only the import feature, but also the export functions (for upload files in the original format)? Or export of data is possible only in the Gettext format , no matter what connector is used for project?
Comments
#1
Since I'm trying to do the same, maybe what I got working so far could be useful to you. I've made a sandbox module with a yaml connector, which allows you to import and export yaml string files, (and also parse them using symfony's parser).
You can get the code (and are welcome to use the issue queue) here: http://drupal.org/sandbox/lucascaro/1551472
Even if it's not the most polished code for a connector, at least it should be an example of how to make a custom connector with import and exporting functionalities.
Also, I'm open to suggestions in how to improve the importing / exporting code (you can see my approach in the module).
#2
Thanks for posting that "example"!
#3
Sure! I'll keep updating it (currently porting it to 7.x) so suggestions are welcome!
#4
I'm also looking into a better way to do the export and have a module working where I've added two keys to the info array returned in hook_l10n_server_connector_info: 'export callback' and 'export file' which would allow to define a custom export function, similar to l10n_community_export (in my module is the l10n_yaml_export).
I think this could be a good way to make l10n_server more flexible and if the module maintainers like the idea I could help making this happen.
#5
I think this sounds like a good idea. For 7.x :)
#6
Great!
As I've said, what I'm doing now in a custom module is allowing for those two new values in hook_l10n_server_connector_info() using either the defined function or the default l10n_community_export function.
I think for 7.x-1.x we could use this method in order to keep 100% compatibility with all existing modules, but I'd suggest rethinking it for 7.x-2.x so we can do fancier things like returning an array of files instead of forcing just one file.
If we rewrite l10n_community_export so it looks for an export callback we could get away with adding this feature with minimal code changes. This will mean that every time l10n_community_export is called (for example, in l10n_packager's l10n_packager_admin_installer_form_submit() l10n_community would automatically check if there's an export function defined and use it or else use the default gettext export.
What do you think?
#7
let's rethink this for 7.x-2.x to maintain compatibility between 6.x-3.x and 7.x-1.x