translation of -dev releases
| Project: | Localization server |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
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..
#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.