(Created page with "Add your proposal in this wiki page, you decide the content of this page, it is your proposal, Happy Coding !! --~~~~--") |
No edit summary |
||
| Line 1: | Line 1: | ||
<h1>Proposal Description</h1> | |||
==An overview of the proposal== | |||
A plug-in for the Geeklog CMS which would enable users to submit translations. It should be lightweight, detachable and as independent of the actual CMS as possible. The detailed proposal is on the Summer Codding ideas webpage as this project was offered initially. | |||
==The need you believe it fulfills== | |||
It will provide and easy to use interface for submitting translations of the CMS or parts of the CMS. The whole system should be design in such a way that it makes the users want to submit proposals at the same time making it convenient for them. | |||
==Relevant experience== | |||
I have knowledge of PHP, SQL and JavaScript, as required on the ideas list. As well as jQuery and it’s plugins. I am in the process of familiarizing myself with the Geeklog API and the CMS itself. | |||
==Implementation== | |||
===General description === | |||
My approach to this is to make a plug in for the CMS. The plug in would update the current user control panel with an additional tab where the user could turn the plugin on/off and in case it is on specify to and from which language he is able to translate. The CMS currently uses PHP arrays to handle language changes in light of that the plugin would create it’s own folder with “translation files”. They would resemble the PHP files the CMS currently uses in structure. In these files we would save the translations. So the translation would not be sent to the remote(original) database every time the user enters a translation but they would rather have to press a button to send their translations. The file would also have to contain the Geeklog username of the user submitting the translation (if available) and the Geeklog version they use. The translations would be saved in these files inside the correct array with the correct key. e.g $LANG_INSTALL = array( 0 => 'Geeklog - Zuverlässigkeit eingebaut' … the reason for files on one side and a database on the other is that the user would probably submit one translation per phrase. More advanced users could use their files immediately and we could even make a tutorial on how to use those files. Or the best case scenario, the plug in would provide them with this option. I imagined however that different users would submit different translations to the main database. We could write a query for the database which would find the most submitted (similar looking) translation for a phrase, that could serve as translation confirmation and would make packing much easier. The admin when approving translations would have to see the original phrase, the proposed translations next to them the number of times a certain translation has been submitted. | |||
===Details about the looks and feels=== | |||
The plugin would add sidebars to sites. The sidebars would host untranslated phrases from the site the user is currently viewing and input boxes for the user to submit their translation. The sidebar would also offer an “Show untranslated text from this site” button”-This would open the same site with all available phrases on the language to which the user translates the gaps would be filled with the original language. This approach would enable the user to have a context of the phrase he is translating. And finally the sidebar would host the “submit translation” button which would patch their translation and send it to a central database. This would be achieved through the Geeklog API so that it does not affect any of the original code. My idea of providing the user to see the context is to use Javascript, the script could find the text to be translated on a certain page and highlight it. I am not 100% sure this would work but I am sure it is worth a try. This would basically mimic what happens when you open search inside a text editor, not as in take the user to every occurrence of the phrase/word but rather as in highlighting the phrase/word on the page. | |||
===Gems=== | |||
Finally to make contributing more appealing to users a gamification system would be put in place. The mentor and I would come up with a set of rules on when to grant gems and more importantly where the user’s gems would be displayed. I guess the best place would be on the users Geeklog profile but this might be too intrusive. | |||
What I would start with is a gamification system similar to CodeCademy’s. Of course it would be adapted to this use case. But basically badges would be designed and awarded. Some of the awards could be: Finishing a logical unit (a unit being a complete array from the language files). Awards for every n submissions, a complete translation submission (as in the whole language file), continuous contribution (adding at least 1 translation every day, or every time the user logs in). A great thing would be to add an option for sharing gems on social networks. | |||
==A (very)rough timeline for the progress== | |||
===May 28th-June 17th:=== | |||
Publish the implementation plan-There is a good chance I could get great suggestions from the community. | |||
Familiarize with the Geeklog API. | |||
===Jun 17th-July 29th=== | |||
Create the interface, make sure it correctly handles page content and that it communicates correctly with Geeklog (adding the additional tab in the control panel) | |||
Implement the “installation”, basically adding the translation files to the plugin folder. | |||
Documenting the work done | |||
===July 29th-September 1st=== | |||
Handling the local saving of the translations. | |||
Implementing the submission of translations. Making sure the plugin behaves correctly in consideration to versions, to user specific text... | |||
Documenting the work. | |||
===September 1st-September 16th=== | |||
Designing the gamification and implementing it. | |||
==Additional details== | |||
The timeline above is very rough, I would design a better one in collaboration with my mentor in the period prior to begin of coding. | |||
If possible I think it would be great if additional to me providing blogs on what has been done on the project my mentor and I could schedule some kind of weekly meeting so he can check on my progress, and give me guidance. | |||
If by any chance I complete this project before GSoC ends I would gladly take on another. If by any chance I fail to finish it during the official GSoC time I will continue working on it past the GSoC deadline. | |||
===Have you communicated with a potential mentor? If so, who?=== | |||
Dirk Haun | |||
Revision as of 13:29, 27 April 2013
Proposal Description
An overview of the proposal
A plug-in for the Geeklog CMS which would enable users to submit translations. It should be lightweight, detachable and as independent of the actual CMS as possible. The detailed proposal is on the Summer Codding ideas webpage as this project was offered initially.
The need you believe it fulfills
It will provide and easy to use interface for submitting translations of the CMS or parts of the CMS. The whole system should be design in such a way that it makes the users want to submit proposals at the same time making it convenient for them.
Relevant experience
I have knowledge of PHP, SQL and JavaScript, as required on the ideas list. As well as jQuery and it’s plugins. I am in the process of familiarizing myself with the Geeklog API and the CMS itself.
Implementation
General description
My approach to this is to make a plug in for the CMS. The plug in would update the current user control panel with an additional tab where the user could turn the plugin on/off and in case it is on specify to and from which language he is able to translate. The CMS currently uses PHP arrays to handle language changes in light of that the plugin would create it’s own folder with “translation files”. They would resemble the PHP files the CMS currently uses in structure. In these files we would save the translations. So the translation would not be sent to the remote(original) database every time the user enters a translation but they would rather have to press a button to send their translations. The file would also have to contain the Geeklog username of the user submitting the translation (if available) and the Geeklog version they use. The translations would be saved in these files inside the correct array with the correct key. e.g $LANG_INSTALL = array( 0 => 'Geeklog - Zuverlässigkeit eingebaut' … the reason for files on one side and a database on the other is that the user would probably submit one translation per phrase. More advanced users could use their files immediately and we could even make a tutorial on how to use those files. Or the best case scenario, the plug in would provide them with this option. I imagined however that different users would submit different translations to the main database. We could write a query for the database which would find the most submitted (similar looking) translation for a phrase, that could serve as translation confirmation and would make packing much easier. The admin when approving translations would have to see the original phrase, the proposed translations next to them the number of times a certain translation has been submitted.
Details about the looks and feels
The plugin would add sidebars to sites. The sidebars would host untranslated phrases from the site the user is currently viewing and input boxes for the user to submit their translation. The sidebar would also offer an “Show untranslated text from this site” button”-This would open the same site with all available phrases on the language to which the user translates the gaps would be filled with the original language. This approach would enable the user to have a context of the phrase he is translating. And finally the sidebar would host the “submit translation” button which would patch their translation and send it to a central database. This would be achieved through the Geeklog API so that it does not affect any of the original code. My idea of providing the user to see the context is to use Javascript, the script could find the text to be translated on a certain page and highlight it. I am not 100% sure this would work but I am sure it is worth a try. This would basically mimic what happens when you open search inside a text editor, not as in take the user to every occurrence of the phrase/word but rather as in highlighting the phrase/word on the page.
Gems
Finally to make contributing more appealing to users a gamification system would be put in place. The mentor and I would come up with a set of rules on when to grant gems and more importantly where the user’s gems would be displayed. I guess the best place would be on the users Geeklog profile but this might be too intrusive.
What I would start with is a gamification system similar to CodeCademy’s. Of course it would be adapted to this use case. But basically badges would be designed and awarded. Some of the awards could be: Finishing a logical unit (a unit being a complete array from the language files). Awards for every n submissions, a complete translation submission (as in the whole language file), continuous contribution (adding at least 1 translation every day, or every time the user logs in). A great thing would be to add an option for sharing gems on social networks.
A (very)rough timeline for the progress
May 28th-June 17th:
Publish the implementation plan-There is a good chance I could get great suggestions from the community. Familiarize with the Geeklog API.
Jun 17th-July 29th
Create the interface, make sure it correctly handles page content and that it communicates correctly with Geeklog (adding the additional tab in the control panel) Implement the “installation”, basically adding the translation files to the plugin folder. Documenting the work done
July 29th-September 1st
Handling the local saving of the translations. Implementing the submission of translations. Making sure the plugin behaves correctly in consideration to versions, to user specific text... Documenting the work.
September 1st-September 16th
Designing the gamification and implementing it.
Additional details
The timeline above is very rough, I would design a better one in collaboration with my mentor in the period prior to begin of coding. If possible I think it would be great if additional to me providing blogs on what has been done on the project my mentor and I could schedule some kind of weekly meeting so he can check on my progress, and give me guidance.
If by any chance I complete this project before GSoC ends I would gladly take on another. If by any chance I fail to finish it during the official GSoC time I will continue working on it past the GSoC deadline.
Have you communicated with a potential mentor? If so, who?
Dirk Haun