Posted by Zoltán Balogh on November 1, 2008 at 8:32am
Jump to:
| Project: | Localization server |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Many cases in the approval state the submitted translations are different. Which translation is the good one? If the administrator don't known the current module, there are not any guidelines for the decision. What is it? Just the module name (no translation), or a menu item too (translation required), a permission, an item of the select list, or etc. Where is this string displayed?
I mean, a View occurrences link helps in a lot of cases, not just for the approval state, in the online translation too.
Comments
#1
I mean the view source of the occurrences, of course.
#2
+1
#3
This could only work consistently, if we store all the source code of all parsed modules. Either we keep it where we extracted (although that was a temp folder), or we don't use a temp folder, or we push source code of all parsed files into the database keyed by pass. That is going to be a huuuge table, mind you. At this point, we don't have source code for any of the parsed packages once we get over parsing them.
If we'd only deal with public drupal.org modules, we could try and figure out a source code link to point to the exact line in a checkout of the module on the cvs.drupal.org web interface, but from previous notes from you, I assume you expect not to limit translation to drupal.org only modules.
More implementation ideas or actual code is welcome! :)
#4
I mean, the sites/(default||other)/files/l10n_server/module_name/version_number is a very good place to extract all modules instead of the temp folder. In the parsing phrase you know, which was the current file, and the current line number, where the parsed string was occurred. I mean, all parsed strings have an ID, and an extra table can store the occurrences (text ID, filename, line number or something like this).
Maybe, in this this case, the database is going to be huuuge, but on localization servers the throttle module is not a required component, and there is enough space for storing these informations. I hope. :D
#5
One possible problem with a public extraction folder is that modules might have code which is dangerous to run in itself. Theoretically, the files folder is protected form running anything named .php or the like, but any hole in that or an l10n_server running without proper .htaccess (eg. on an IIS or otherwise), could end up with an arbitrary code execution vulnerability due to public runnable PHP code. If we use a directory, then that should be IMHO out of the webroot.
#6
Yes, that is true, the security is the first. But I think, a directory out of the web root with read-write access is not impossible, if somebody wants to run a localization server. Then the storing of modules is solved. Remained the saving of occurrences to the database, and the modifications on the information panel.
And maybe need a cron cleanup process too, which is clear from the database the unnecessary datas (missing, manually deleted files, etc).
#7
Exact occurrence data is already collected, since it is required for .po file generation.
#8
Then close this one.