Jump to:
| Project: | Localization server |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (works as designed) |
Issue Summary
I think if someone would like to commit the translation to d.o cvs then the best practice would be to export the translation of the latest -dev release, so the next official module release would mostly contain the translation of all new strings also..
questions: (about l10n_localpacks connector)
1. if I upload a new dev release will be that file rescanned automatically? As I know if the given release exists in the db then the file won't be rescanned, but as I see there is a special case when a file date is changed inside l10n_localpacks_save_data() what could be enough for this case.
2. will it add new string to the dev release or it will delete previous sources? I don't see the delete of previous strings in the code, but maybe it will have a new id or something.. So, does the -dev export contain the correct strings (the strings from the uploaded dev file and only those)?
Maybe I should just test it..
Comments
#1
The general idea is that -dev versions are volatile, so we'd ask maintainers to tag their modules as RC or something before they do a release, so translators can work on it. Also, translations might not end up packaged with the releases at the end, so people can keep translating while the module is already out (unlike the current situation).
As far as the l10n_localpacks implementation goes, yes, if the file timestamp or the size is different, it should reparse the file, at least that is what I remember. Also, it just adds stuff, does not remove, so old and unused stuff will be kept for history. That might be a very bad or very good thing.
#2
The idea to froze strings before the final release is nice, but the problem is that strings are added and changed in stable releases (even in Drupal core) and that won't change in the near future.
I would like to see correct translations packaged with the module, and do not obligate people to download translation of latest release from the translation server.
My simple request is to delete -dev strings with old timestamp after the new -dev package is parsed, as these unused strings are mostly just wrong, like missing dots and commas or typos. The history is kept with the official releases.
The translation export of -dev should only contain the strings from the latest uploaded -dev release..
#3
"My simple request is to delete -dev strings with old timestamp after the new -dev package is parsed, as these unused strings are mostly just wrong, like missing dots and commas or typos."
I am looking into a way to translate dev releases as well. I liked the 'timestamp' idea, but there is nothing in the current l10n_community_* tables available to have this working out of the box. Adding a timestamp field to the l10n_community_line table might look like a solution, but why bother adding a timestamp field. Why not simply a tiny int, representing a boolean to indicate the source string was found or not during the last parsed cycle. All those with 0 could be removed from l10n_community_line. Once done, some strings might be orphaned and cleaned up as well which is already in place.
I think i will cook up a patch for this, but share your thoughts if this can be done much easier.
#4
the timestamp is there: l10n_community_project.last_parsed
#5
It's in the project table indeed, but it needs to be in the line table as well, not? How can you find out otherwise what strings are not in the project anymore.
#6
Adding the dev release on nightly basis and removing the old one proved in fact to be fairly easy. This is the function to remove a release.
<?php
/**
* Removing a l10n release
* @param $rid release id
*/
function [l10n_helper_module]_remove_release($rid) {
if ($release = db_fetch_object(db_query('SELECT title, download_link FROM {l10n_community_release} WHERE rid = %d', $rid))) {
db_query('DELETE FROM {l10n_community_release} WHERE rid = %d', $rid);
db_query('DELETE FROM {l10n_community_line} WHERE rid = %d', $rid);
file_delete(variable_get('l10n_localpacks_directory', NULL) . '/' . $release->download_link);
watchdog('[l10n_helper_module]', 'Successfully removed release @title', array('@title' => $release->title));
return TRUE;
}
else {
watchdog('[l10n_helper_module]', 'Could not remove release @title', array('@title' => $release->title), WATCHDOG_ERROR);
}
return FALSE;
}
?>
#7
@toemaz: this will leave orphan strings in the database, that is strings stored just for a dev release, which might never be used again. Also, people might rush to translate stuff which will quickly become obsolete. It does not sound nice to make translators work when their stuff is thrown out as soon as 24 hours later, is it?
#8
@Gábor: I am sure toemaz is working on a translation server to translate a software which isn't Drupal, so I think the "24 hours later" argument does not apply for everyone..
#9
Indeed, we are using the l10n_server for translating the desktop software MuseScore.
I'm still investigating what could be the right interval for importing the dev release but one thing is for sure, so the nightly import is certainly under debate. It will depend on what most of the translators are requesting, so currently, I'm leaving it open.
Some other interesting details perhaps:
MuseScore uses ts files instead of po files. In order to import these ts files, I use the querypath module to read in the xml based ts file and dump it as a .module file. It's 10 lines of code. I preserve the context by using the D7 t function and hacked l10n_server to believe it's a D7 module. It works flawless.
An export from the database to ts is done again with querypath using the original ts file as a template. The translations are then written into the dom document. Finally, the ts files are converted to qm.
I'm still tweaking bits and pieces, and once done, I'll make a write up. In the meantime, you can see the translation server at http://translate.musescore.org
#10
@toemaz: I think you can easily name the release *with a timestamp in the filename*, thus stepping over the -dev issue. Then you can use your code to remove older releases. There are various timestamps stored for projects and releases, so you can use the file timestamp for example, to drop earlier dev releases.
I'm always looking for improvements to be made to make the localization server more generic and applicable to all kinds of software, not just Drupal :) I've written a blog post about this at http://hojtsy.hu/blog/2010-may-05/using-drupal-collaborative-software-tr... and making progress with issues like #1102758: Dramatically simplify and generalize export tool especially happily when it both makes sense for Drupal and everybody else. Any feedback on how can I make this module suite better for non-Drupal projects is appreciated.
#11
Hi Gábor,
I have been closely following the latest development of l10n_server. Soon we will pull in a new branch into our server at http://translate.musescore.org and while making adjustments to the code, I will also update to the latest l10n_server version. I'm sure I will come up with a list of things to improve and I will report back in the issue tracker as I did more than one year ago. Cheers!