Closed (won't fix)
Project:
Drupal.org CVS applications
Component:
new project application
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
17 Nov 2010 at 21:08 UTC
Updated:
11 Sep 2019 at 13:11 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
niccottrell commentedComment #2
drupalshrek commentedHi,
Sounds promising.
Please could you add here the required comparison with any existing Drupal modules. If none, at least the nearest few in a similar domain (I suppose translation) with why they don't do at all what you've done.
Comment #3
drupalshrek commentedComment #4
avpadernoHello, and thank you for applying for a CVS account. I am changing the status as per previous comment, and adding the review tags.
Comment #5
niccottrell commentedOne related module is http://drupal.org/project/translation_management . This module, however, stores content translation back into the local database, whereas the Sprawk module completely abstracts away the need to data management of the individual translation strings. Those are stored securely on the sprawk.com system where they can easily be reused for non-website usages (like translation emails or Word documents).
Another module is http://drupal.org/project/gtrans which only connects to Google and has no authentication or customization functionality.
Also http://drupal.org/project/active_translation which just assists in the display of translated nodes (The Sprawk paradigm does not require a node per-language, but simply translates the user content of a node to the best language available for the current user).
Another new module is http://drupal.org/project/dakwak which is a wrapper to Google translate which introduces some language switcher blocks.
I don't envisage the module getting much more complex than it already is. It mostly just manages the transfer and retrieval of data from the external Sprawk service (which does most of the complicated work). If there's interest we're happy to start work on a Drupal 7 version this year.
Comment #6
niccottrell commentedSorry - forgot to change it back to "needs review"
Comment #7
niccottrell commentedI've just found some bugs that I will fix and then upload a new zip.
Comment #8
niccottrell commentedThis version has some bugfixes, added inline comments plus an extended INSTALL.txt
Comment #9
avpadernoThis review is only partial.
Avoid to escape the string delimiter inside a string, especially if the string is passed to
t().Using
l()in that way is not correct, as reported in the documentation fort(), which suggests to use code similar to the following:That code should go in
hook_init(), or (better) in any form builder where those files are required. That would avoid to load them in pages handled by other modules.The code should use Drupal behaviors.
Strings shown in the user interface should be translated (in that case, consider using
t()-placeholders).<b>, and<br>are not tags that should appear in XHTML output (which is the output returned from Drupal).CSS styles should be applied using a class or a HTML ID. URLs, and mail addresses should be passed in the string (which needs to be translated) through
t()-placeholders.Why isn't the code using an hidden form field?
The first argument of
t()is a literal string; any dynamic value (including the result of concatenating two strings) is not translated (which means that callingt()with a dynamic value is like not calling it at all).The reason is that the strings to translate are found from a script that looks for any strings passed to
t(), and save them in the translation template. That script is not able to get the value of a variable, as the module is not executed to get such values.Events are normally attached to HTML elements using Drupal behaviors.
Comment #10
niccottrell commentedThanks for the review. I've attached a new version with fixes...
1. The JS has been converted to use jQuery for AJAX and the old methods removed
2. Fixed usages of t() and l()
3. Moved js and css includes to sprawk_init
4. Changed button to use Drupal behaviours
5. Refactored bad HTML tags out of strings
6. Fixed to meet Drupal standards
7. This is used for debugging encoding problems during initial setup. It's necessary to see the text in the HTML source, hence the comment
8. Fixed
9. Done.
Comment #11
avpadernoHello, niccottrell. I am sorry nobody made any further review of the code, and you had to wait.
The license of the JavaScript file is then different from GPL license, which the license you agree to use for the files you commit to the repository.
version =line should be removed from the .info file.The string delimiter should not be escaped inside a string, especially when the string is the argument passed to
t().I don't see any reason to split the form field description in two; it would be better to use a single string, if both the strings are used only once in all the module code.
The module should use CSS class names that are prefixed with its short name, to avoid conflict with existing modules, including Drupal core modules.
The prefix should probably be a separated form field, and it should use
format_plural().Form fields are generated through the form API.
JavaScript events are added through Drupal behaviors.
It would be enough to use
The code should probably use
url().Drupal has the
decode_entities()function that doesn't depend from a specific PHP version.The function call is missing an argument.
Use placeholders.
The function is not defined in PHP4, while Drupal 6 is still compatible with PHP4; if the module needs PHP5, then it needs to declare this dependency.
The
$languagevariable is not defined; setting$language->languagedoesn't have the desired effect.I guess the code is referring to the global
$languagevariable, even if it doesn't seem a good idea to change that variable for testing purposes without to restore its original value.'sprawk_%'.)In this case, it would be better to use
l().The code outputs a HTML table without using a theme function that Drupal has.
There is a Drupal function to use in those cases.
Comment #12
niccottrell commentedThanks kiamlaluno,
Here are the changes you've suggested.
1. I've removed this file and added instructions on how to download and install it
8. We looked into using url() but it doesn't seem to do anything for full urls so we thought it was more efficient to leave it as is
14. We made php5 a requirement so that we can use json_decode. This requirements is listed in INSTALL.txt
Best,
Nic.
Comment #13
niccottrell commentedI've found some bugs, added some debug and improved a few things.
Comment #14
arianek commentedHi. Please read all the following and the links provided as this is very important information about your CVS Application:
Drupal.org has moved from CVS to Git! This is a very significant change for the Drupal community and for your application. Please read the following documentation on how this affects and benefits you and the application process:
Migrating from CVS Applications to (Git) Full Project Applications
Comment #15
avpadernoAs per previous comment, I am setting this issue to won't fix.
Since new users can now create full projects, applications have a different purpose and they are handled on a different issue queue. See Apply for permission to opt into security advisory coverage for more information.
Comment #16
avpaderno