Changes between Version 3 and Version 4 of BluePrintTransliteration


Ignore:
Timestamp:
12/29/11 21:22:18 (10 years ago)
Author:
Fran Boon
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintTransliteration

    v3 v4  
    44
    55== Possible use-case ==
    6 The CAP broker, which is currently work-in-progress, supports messages in different languages. Helpers might want to share messages in county-specific letters.
     6The CAP broker, which is currently work-in-progress, supports messages in different languages. Helpers might want to share messages in country-specific letters.
    77
    88== Technical side ==
     
    2020
    2121=== Implementation ===
    22 If we would decide to develop the transliteration input ourselves, the recommended approch is a S3Widget, as it is easy to implement into the existing structures of Eden (a simple widget=TransliterationTextarea in the model is the only thing we would need to change to enable transliteration for a text-value). As everything has to be real-time, the Widget should fire a AJAX request. The problem is the data source. Even if the websites above would allow us to use their data, we would have to bring the given data into a consistent format like XML or JSON.
    23 Furthermore everything needs to be tested VERY much, as the data might be not 100% correct. Lifes may depend on it and if a CAP message, for instance, is not correct because the transliteration engine made a mistake, we have a serious problem. Because of this we need native speakers of these languages to test them.
    24 The last aspect that needs to be mentioned is the work required to maintain everything. If there is an update by one of the transliteration services requireing us to rebuild our JSON/XML files, everything might get outdated.
     22If we would decide to develop the transliteration input ourselves, the recommended approach is an S3Widget, as it is easy to implement into the existing structures of Eden (a simple widget=TransliterationTextarea in the model is the only thing we would need to change to enable transliteration for a text-value). As everything has to be real-time, the Widget should fire an AJAX request. The problem is the data source. Even if the websites above would allow us to use their data, we would have to bring the given data into a consistent format like XML or JSON.
     23Furthermore everything needs to be tested a LOT, as the data might not be 100% correct. Lives may depend on it and if a CAP message, for instance, is not correct because the transliteration engine made a mistake, we have a serious problem. Because of this we need native speakers of these languages to test them.
     24The last aspect that needs to be mentioned is the work required to maintain everything. If there is an update by one of the transliteration services requiring us to rebuild our JSON/XML files, everything might get outdated.
    2525
    26 Another point is the GUI. We need a textarea with similar functions like Eclipse's autocomplete or Visual Studio's IntelliSense, a dropdown with possible meanings a letter combination can have. The only suitable solution is [[http://wiki.jqueryui.com/w/page/12137993/ListBuilder | available here]]. A JQuery plugin needing a bit of styling, but supporting JSON as a data source.
     26Another point is the GUI. We need a textarea with similar functions like Eclipse's autocomplete or Visual Studio's IntelliSense, a dropdown with possible meanings a letter combination can have. The only suitable solution found so far is [[http://wiki.jqueryui.com/w/page/12137993/ListBuilder | jQueryUI ListBuilder]]. This needs a bit of styling, but supports JSON as a data source.
    2727
    2828== Suggestion ==
    29 According to the points explained above, a transliteration engine is quite much work, as we have no consistent database of roman -> Indian, Chineese, Cyrillic characters which we could use. As long as we are not able to find one, an implementation of a transliteration engine is not recommended. If we would find a professional and consistent database we could start to implement the feature using the JQuery plugin explained above.
    30 
    31  
     29According to the points explained above, a transliteration engine is quite a lot of work, as we have no consistent database of roman -> Indian, Chinese, or Cyrillic characters which we could use. As long as we are not able to find one, an implementation of a transliteration engine is not recommended. If we could find a professional and consistent database we could start to implement the feature using the JQuery plugin explained above.