***I'm pretty sure that this should be seperated into at least two (if not more) tasks, but I'm putting it up here as one for the moment as it is to hopefully get some feedback on if/where it should be split. We could also make it so they can just choose a few of the items (or groups of items, since some belong together)***

The Auto Translate Module ( http://drupal.org/project/i18n_auto ) aims to assist with translations on Drupal sites by allowing content creators to press a button which scrapes the text area of a node, queries a third party translation service, and pastes the resulting translation which can then be edited and posted as a translation. When this module is complete it will greatly reduce the amount of time needed to translate a site, making it much easier to maintain multi-lingual content-heavy Drupal sites. However, the module is still in a development release, and needs a few significant improvements to bring it to the level of a full release.

Tasks
The following need to be completed before the module can be released. The student is expected to complete at least X of these tasks for this project.
1) it needs a checkbox on node type admin screens. then the node->body will work w/ that
2) it needs to be activated for cck text fields (and #2 should only happen when #1 is true)
3) a link to add autotranslate to any textarea (currently it only works on text areas on the node submissions page)
4) an administrators option to decide where the translation links should appear and an "on/off" link under text areas
5) make the other 2 translation providers functional (currently only google translation works) and research their Terms of Service (TOS) to ensure that the module doesn't put the users into violation of their rules.
6) research new providers, and their TOS
7) Write a warning message to be displayed on activation of module or configuration of its settings about providers TOS
8) Add logos/links to provider's TOS on the admin page, and possibly on the auto translate form element
9) integrate the with the i18n and locale modules, to allow the module to autofill i18n fields and determine the translation via the locale settings.
10) make sure that accented characters are formatted correctly.

Fixes for these items should be submitted to the issue queue as patches. To complete these tasks the student will have to demonstrate that the fixes work in at least 3 browsers.

Resources
Google Translate - http://www.google.com/translate_t
Yahoo Translate - http://babelfish.yahoo.com/
Internationalization Module - http://drupal.org/project/i18n
CAPTCHA Module - http://drupal.org/project/captcha

Primary Contact(s)
Aaorn Winborn (aaron) with help from Alex Urevick-Ackelsberg (Alex UA)

Comments

aaron’s picture

aaron commented

The module actually works with CCK text fields, although it doesn't always place the translate buttons directly below the text area, making it sometimes difficult for the user to find. I've removed that item, and created a new item to fix the placement.

Here's a breakdown and slight rewrite of the items. I envision three groupings of tasks, although am not attached to this idea. I created a fourth grouping, for Usability UI changes.

Administrative
1) Add a checkbox on Node Type Administration screens. Ensure that if this is checked, then all text areas of that node type will have an attached Translate Buttonset, and that if it is not checked, they won't (although that may be overridden with a later task).
2) Ensure that attached Translate Buttonsets appear directly below their associated text areas.
3) Add an "on/off" link below each text area, visible only to administrators, that will attach a Translate Buttonset to that text area (assuming the editor has the proper privilege). This will override the first task, which simply turns on all text areas for a node type.

Translation Services
1) Research at least two translation services, including Yahoo Babelfish, and their Terms of Service (TOS).
2) Make at least two translation providers functional (currently only Google translation works).
3) If the TOS warrants it, write and display a warning message about provider's TOS to be displayed on activation of the module and/or configuration of its settings, to help users not violate their rules.
4) Add logos/links to provider's TOS on the admin page and on the auto translate form element (although allow admins to disable their display on the form element).
5) Ensure that accented characters are formatted correctly with at least one translation service. Google flattens those characters. A patch has been written, but doesn't seem to work with PHP4. Test against the other providers, and test against both PHP4 and PHP5 if possible, and either report the findings, and/or optionally fix the problem of Google.

i18n Integration
1) Make the default 'from' language equal to the site's configured location via the Locale settings.
2) Make the default 'to' language equal to the node page's set 'to' language (this may require jquery to read the relevant element). Note that this task may have recently be completed.
3) Remove i18n dependency. Besides removing that from the .info file, ensure the module actually works without i18n installed. If there are elements of the module that require it, place any required calls in module_exists checks, and ensure the basic functionality works without it (even if this reduces the functionality, such as removing automatic language selection). However, it is ok to require the Locale module (which will require putting that into the .info file if not already present).
4) Allow translators to manually select the 'to' and 'from' languages from drop-downs in the Translation buttonsets. Have the available languages pre-filled from Locale settings. Allow administrators to disable languages from those drop-downs with checkboxes in an administrative screen, but only list languages installed on the site from Locale.

Usability
1) Examine the current User Interface (UI) of the Location Buttonsets attached below each text area.
2) Propose at least one alternative UI and/or workflow for the Auto Translate module and create an illustration, diagram, and/or screenshot of the proposal.
3) Implement the changes required for an alternative UI and/or workflow, and submit as a patch for review.
4) Find at least 3 volunteers, at least one of whom is not familiar with Drupal, that you are able to observe while using the computer. Have each of them use both the unpatched and modified Auto Translate module, by translating content in a text area. Interview the volunteers, asking their impressions of both UI's. Submit a report of your findings.

aaron’s picture

aaron commented

spelling/grammar:

i18n #2: "may have recently *been* completed"

My name is spelled Aaron.

Thanks for the great proposal, Alex!

aaron’s picture

aaron commented

1) Research at least two translation services, other than Google Translation but including Yahoo Babelfish,

aaron’s picture

aaron commented

actually, google's TOS needs examination too. so maybe 1 should be:

1) Research at least two translation services, other than Google but including Yahoo Babelfish, and their Terms of Service (TOS). Also research Google's TOS. Report any flags you notice about their TOS, and feasibility of integrating their service into the Auto Translate module. (Google has already been integrated, although note item 5).

aclight’s picture

aclight commented
Component: GHOP Task » Task idea
Status: Active » Needs work

A.) You should specify the branch of the module to create patches against and specify that patches need to be marked RTBC.

B.) For research X translation services, I would recommend giving a list of acceptable services and having the student choose from that list (and you can require Bablefish if you want).

C.) For "1) Research at least two translation services, including Yahoo Babelfish, and their Terms of Service (TOS).", what does that mean? What about the services should they research? Try to be a bit more specific than even in comment #4. How should student submit their research? As a handbook page, just follow up to the issue, etc.

D.) "2) Make the default 'to' language equal to the node page's set 'to' language (this may require jquery to read the relevant element). Note that this task may have recently be completed."

If it's completed already, why is it listed here?

I like the way you've split these into 4 tasks with a similar theme. My problem is that if for each GHOP task you plan to have 3 or 4 separate drupal.org issues, this is going to be really difficult to keep track of from our end. It would be much easier if there is just one drupal.org issue per GHOP task, but in some cases that might not be ideal from an issue tracking standpoint. I'll leave that up to you, but it will make our lives easier if it's just one issue per task.

alex ua’s picture

alex ua commented

***Here's a second version. I'm asking here that they choose to take on between 1 and 4 of the tasks for now, and if they take one or two, then we'll reopen the task when they finish. Does that sound good? I'm still waiting for clarification from Aaron on the last question raised by aclight***

The Auto Translate Module ( http://drupal.org/project/i18n_auto ) aims to assist with translations on Drupal sites by allowing content creators to press a button which scrapes the text area of a node, queries a third party translation service, and pastes the resulting translation which can then be edited and posted as a translation. When this module is complete it will greatly reduce the amount of time needed to translate a site, making it much easier to maintain multi-lingual content-heavy Drupal sites. However, the module is still in a development release, and needs a few significant improvements to bring it to the level of a full release.

A) Administrative
1) Add a checkbox on Node Type Administration screens. Ensure that if this is checked, then all text areas of that node type will have an attached Translate Buttonset, and that if it is not checked, they won't (although that may be overridden with a later task).
2) Ensure that attached Translate Buttonsets appear directly below their associated text areas.
3) Add an "on/off" link below each text area, visible only to administrators, that will attach a Translate Buttonset to that text area (assuming the editor has the proper privilege). This will override the first task, which simply turns on all text areas for a node type.

B) Translation Services
1) Research at least two translation services, which must include yahoo babelfish and at least one of the following: InterTran, Transparent, WorldLingo, and Windows Live Translator. This part of the task will involve checking to see if the site has an api, and reading through their Terms of Service (TOS) to ensure that module is being used legally. These findings should be submitted back to the issue queue for review.
2) Make at least two translation providers functional (currently only Google translation works).
3) If the TOS warrants it, write and display a warning message about provider's TOS to be displayed on activation of the module and/or configuration of its settings, to help users not violate their rules.
4) Add logos/links to provider's TOS on the admin page and on the auto translate form element (although allow admins to disable their display on the form element).
5) Ensure that accented characters are formatted correctly with at least one translation service. Google flattens those characters. A patch has been written, but doesn't seem to work with PHP4. Test against the other providers, and test against both PHP4 and PHP5 if possible, and either report the findings, and/or optionally fix the problem of Google.

C) i18n Integration
1) Make the default 'from' language equal to the site's configured location via the Locale settings.
2) Make the default 'to' language equal to the node page's set 'to' language (this may require jquery to read the relevant element). Note that this task may have recently be completed.
3) Remove i18n dependency. Besides removing that from the .info file, ensure the module actually works without i18n installed. If there are elements of the module that require it, place any required calls in module_exists checks, and ensure the basic functionality works without it (even if this reduces the functionality, such as removing automatic language selection). However, it is ok to require the Locale module (which will require putting that into the .info file if not already present).
4) Allow translators to manually select the 'to' and 'from' languages from drop-downs in the Translation buttonsets. Have the available languages pre-filled from Locale settings. Allow administrators to disable languages from those drop-downs with checkboxes in an administrative screen, but only list languages installed on the site from Locale.

D) Usability
1) Examine the current User Interface (UI) of the Location Buttonsets attached below each text area.
2) Propose at least one alternative UI and/or workflow for the Auto Translate module and create an illustration, diagram, and/or screenshot of the proposal.
3) Implement the changes required for an alternative UI and/or workflow, and submit as a patch for review.
4) Find at least 3 volunteers, at least one of whom is not familiar with Drupal, that you are able to observe while using the computer. Have each of them use both the unpatched and modified Auto Translate module, by translating content in a text area. Interview the volunteers, asking their impressions of both UI's. Submit a report of your findings.

All patches should be submitted as patches against the 5.x-1.x-dev version of the module.

Resources
Google Translate - http://www.google.com/translate_t
Yahoo Translate - http://babelfish.yahoo.com/
Internationalization Module - http://drupal.org/project/i18n
CAPTCHA Module - http://drupal.org/project/captcha

Primary Contact(s)
Aaron Winborn (aaron) with help from Alex Urevick-Ackelsberg (Alex UA)

alex ua’s picture

alex ua commented

Sorry, I left out a sentence before the task listings. It should have read:

"For this task the student will complete at least one, and as many as four, of the lettered tasks below."

aclight’s picture

aclight commented

We don't like leaving things so open ended, so I'd suggest that you choose how many the student should do. It's fine if you want to create multiple issues right now--we have plenty left in our allotment. Without looking at the module, I would guess that 1 or 2 of the blocks of tasks would be good. Maybe now that school is back in session, you could do one block per task. Some of these are probably a little easier than others, but that will help spread out the difficulty of the tasks across a broad range.

alex ua’s picture

alex ua commented

Sounds good- I'll make each into its own task (i.e. 4 separate tasks). Do you want me to break them into separate items here, or just in the Auto Translate queue when it gets approved? (The beginning and ending will remain the same for all of them). I'll be labeling them along the lines of:
Help bring the Auto Translate module out of Dev - 1 - Translation Services

aclight’s picture

aclight commented

I think we get the point. There's no need to create 4 separate issues here for approval. Just remember that once you submit to the Google tracker, there is no possibility to edit the issues.

alex ua’s picture

alex ua commented

***OK got an answer from Aaron on the question, I also realized that I missed one of his rewrites, so here are the (hopefully) finished tasks**

The Auto Translate Module ( http://drupal.org/project/i18n_auto ) aims to assist with translations on Drupal sites by allowing content creators to press a button which scrapes the text area of a node, queries a third party translation service, and pastes the resulting translation which can then be edited and posted as a translation. When this module is complete it will greatly reduce the amount of time needed to translate a site, making it much easier to maintain multi-lingual content-heavy Drupal sites. However, the module is still in a development release, and needs a few significant improvements to bring it to the level of a full release.

To complete this task the student must complete the following: /** just a reminder that each of these will be posted as its own issue */

Help bring the Auto Translate module out of Dev--1--Administration Upgrades
1) Add a checkbox on Node Type Administration screens. Ensure that if this is checked, then all text areas of that node type will have an attached Translate Buttonset, and that if it is not checked, they won't (although that may be overridden with a later task).
2) Ensure that attached Translate Buttonsets appear directly below their associated text areas.
3) Add an "on/off" link below each text area, visible only to administrators, that will attach a Translate Buttonset to that text area (assuming the editor has the proper privilege). This will override the first task, which simply turns on all text areas for a node type.

Help bring the Auto Translate module out of Dev--2--Improve Translation Services
1) Research at least two translation services, which must include yahoo babelfish and at least one of the following: InterTran, Transparent, WorldLingo, and Windows Live Translator. Also research Google's TOS. Report any flags you notice about their TOS, and feasibility of integrating their service into the Auto Translate module. (Google has already been integrated, although note item 5).This part of the task will involve checking to see if the site has an api, and reading through their Terms of Service (TOS) to ensure that module is being used legally. These findings should be submitted back to the issue queue for review.
2) Make at least two translation providers functional (currently only Google translation works).
3) If the TOS warrants it, write and display a warning message about provider's TOS to be displayed on activation of the module and/or configuration of its settings, to help users not violate their rules.
4) Add logos/links to provider's TOS on the admin page and on the auto translate form element (although allow admins to disable their display on the form element).
5) Ensure that accented characters are formatted correctly with at least one translation service. Google flattens those characters. A patch has been written, but doesn't seem to work with PHP4. Test against the other providers, and test against both PHP4 and PHP5 if possible, and either report the findings, and/or optionally fix the problem of Google.

Help bring the Auto Translate module out of Dev--3-- i18n Integration
1) Make the default 'from' language equal to the site's configured location via the Locale settings.
2) Make certain the default 'to language' works when the site's default 'to language' is other than English. Ensure that the editor is able to override this.
3) Remove i18n dependency. Besides removing that from the .info file, ensure the module actually works without i18n installed. If there are elements of the module that require it, place any required calls in module_exists checks, and ensure the basic functionality works without it (even if this reduces the functionality, such as removing automatic language selection). However, it is ok to require the Locale module (which will require putting that into the .info file if not already present).
4) Allow translators to manually select the 'to' and 'from' languages from drop-downs in the Translation buttonsets. Have the available languages pre-filled from Locale settings. Allow administrators to disable languages from those drop-downs with checkboxes in an administrative screen, but only list languages installed on the site from Locale.

Help bring the Auto Translate module out of Dev--4--Usability
1) Examine the current User Interface (UI) of the Location Buttonsets attached below each text area.
2) Propose at least one alternative UI and/or workflow for the Auto Translate module and create an illustration, diagram, and/or screenshot of the proposal.
3) Implement the changes required for an alternative UI and/or workflow, and submit as a patch for review.
4) Find at least 3 volunteers, at least one of whom is not familiar with Drupal, that you are able to observe while using the computer. Have each of them use both the unpatched and modified Auto Translate module, by translating content in a text area. Interview the volunteers, asking their impressions of both UI's. Submit a report of your findings.

All patches should be submitted as patches against the 5.x-1.x-dev version of the module.

Resources
Google Translate - http://www.google.com/translate_t
Yahoo Translate - http://babelfish.yahoo.com/
Internationalization Module - http://drupal.org/project/i18n
CAPTCHA Module - http://drupal.org/project/captcha

Primary Contact(s)
Aaron Winborn (aaron) with help from Alex Urevick-Ackelsberg (Alex UA)

aclight’s picture

aclight commented

Could you include a specific deliverables section in each of these? Something like this:

Deliverables:
This task will be considered complete when a patch against the 5.x-1.x-dev version of the module is submitted and has been marked as RTBC.

In that deliverables, please indicate whether all subtasks (ie. 1-4 or 1-5) should be in separate patches (and if so, should those be in separate issues) or is it OK to include the code for all changes in a GHOP task in one patch.

Other than this, these are good to go.

aaron’s picture

aaron commented

I think it should be ok to have code for all changes in a GHOP task in one patch -- I split them up so that all code in a section should be related, so it won't be too difficult for me to sort out what they're doing when reviewing a patch.

The deliverables sounds fine to me as well. The Usability task might be slightly different, since it requires a report, and the patch may not actually be committed, especially if the report favors the current UI. However, it could still be marked RTBC to close the task.

Thanks! It all looks ready otherwise.

Aaron Winborn

alex ua’s picture

alex ua commented

***Finished?**

The Auto Translate Module ( http://drupal.org/project/i18n_auto ) aims to assist with translations on Drupal sites by allowing content creators to press a button which scrapes the text area of a node, queries a third party translation service, and pastes the resulting translation which can then be edited and posted as a translation. When this module is complete it will greatly reduce the amount of time needed to translate a site, making it much easier to maintain multi-lingual content-heavy Drupal sites. However, the module is still in a development release, and needs a few significant improvements to bring it to the level of a full release.

To complete this task the student must complete the following: /** just a reminder that each of these will be posted as its own issue */

Help bring the Auto Translate module out of Dev--1--Administration Upgrades
1) Add a checkbox on Node Type Administration screens. Ensure that if this is checked, then all text areas of that node type will have an attached Translate Buttonset, and that if it is not checked, they won't (although that may be overridden with a later task).
2) Ensure that attached Translate Buttonsets appear directly below their associated text areas.
3) Add an "on/off" link below each text area, visible only to administrators, that will attach a Translate Buttonset to that text area (assuming the editor has the proper privilege). This will override the first task, which simply turns on all text areas for a node type.

Help bring the Auto Translate module out of Dev--2--Improve Translation Services
1) Research at least two translation services, which must include yahoo babelfish and at least one of the following: InterTran, Transparent, WorldLingo, and Windows Live Translator. Also research Google's TOS. Report any flags you notice about their TOS, and feasibility of integrating their service into the Auto Translate module. (Google has already been integrated, although note item 5).This part of the task will involve checking to see if the site has an api, and reading through their Terms of Service (TOS) to ensure that module is being used legally. These findings should be submitted back to the issue queue for review.
2) Make at least two translation providers functional (currently only Google translation works).
3) If the TOS warrants it, write and display a warning message about provider's TOS to be displayed on activation of the module and/or configuration of its settings, to help users not violate their rules.
4) Add logos/links to provider's TOS on the admin page and on the auto translate form element (although allow admins to disable their display on the form element).
5) Ensure that accented characters are formatted correctly with at least one translation service. Google flattens those characters. A patch has been written, but doesn't seem to work with PHP4. Test against the other providers, and test against both PHP4 and PHP5 if possible, and either report the findings, and/or optionally fix the problem of Google.

Help bring the Auto Translate module out of Dev--3-- i18n Integration
1) Make the default 'from' language equal to the site's configured location via the Locale settings.
2) Make certain the default 'to language' works when the site's default 'to language' is other than English. Ensure that the editor is able to override this.
3) Remove i18n dependency. Besides removing that from the .info file, ensure the module actually works without i18n installed. If there are elements of the module that require it, place any required calls in module_exists checks, and ensure the basic functionality works without it (even if this reduces the functionality, such as removing automatic language selection). However, it is ok to require the Locale module (which will require putting that into the .info file if not already present).
4) Allow translators to manually select the 'to' and 'from' languages from drop-downs in the Translation buttonsets. Have the available languages pre-filled from Locale settings. Allow administrators to disable languages from those drop-downs with checkboxes in an administrative screen, but only list languages installed on the site from Locale.

Help bring the Auto Translate module out of Dev--4--Usability
1) Examine the current User Interface (UI) of the Location Buttonsets attached below each text area.
2) Propose at least one alternative UI and/or workflow for the Auto Translate module and create an illustration, diagram, and/or screenshot of the proposal.
3) Implement the changes required for an alternative UI and/or workflow, and submit as a patch for review.
4) Find at least 3 volunteers, at least one of whom is not familiar with Drupal, that you are able to observe while using the computer. Have each of them use both the unpatched and modified Auto Translate module, by translating content in a text area. Interview the volunteers, asking their impressions of both UI's. Submit a report of your findings.

Deliverables:
This task will be considered complete when a single patch (in the case of the UI section, it will be a single document) against the 5.x-1.x-dev version of the module is submitted and has been marked as RTBC.

Resources
Google Translate - http://www.google.com/translate_t
Yahoo Translate - http://babelfish.yahoo.com/
Internationalization Module - http://drupal.org/project/i18n
CAPTCHA Module - http://drupal.org/project/captcha

Primary Contact(s)
Aaron Winborn (aaron) with help from Alex Urevick-Ackelsberg (Alex UA)

aclight’s picture

aclight commented
Status: Needs work » Reviewed & tested by the community

go for it.

alex ua’s picture

alex ua commented
Status: Reviewed & tested by the community » Closed (fixed)

This has been submitted, and is now GHOP task 140, 141, 142, and 143.

It can also be found under the following Issues on Drupal.Org under the i18n_auto issue queue:
http://drupal.org/node/209250
http://drupal.org/node/209254
http://drupal.org/node/209257
http://drupal.org/node/209259