Multilingual E-Learning: Proposal For an Application
This must have been the mid to late 2000s. I had begun my second Masters. It wasn’t described as an “online” learning format. If I remember correctly, I negotiated with the university in the UK to allow me to do the three-year course remotely (I was living in Japan at the time and the options for distance learning Technical Communication were very limited). They accepted, on the provisos that I met all the standard deadlines, contributed regularly to the Blackboard discussions, kept up with the reading, and paid for the printed material to be sent to me by courier. (They also wanted three printed and bound copies of the dissertation couriering to them, which cost me a small fortune!) I think I might have paid more than a regular student, too, but I forget. Anyway, while doing this, I began to have thoughts about integrating translation and/or language enhancement functionality into Blackboard, the online learning platform (very similar to Moodle). What follows is a formal articulation of my ideas. Needless to say, I never realised any of these myself, but much of this functionality has become available – if not successfully integrated into e-learning platforms.
Background
E-learning offers far greater flexibility to a much broader range of people, particularly recreational learners or people in fulltime employment. Its popularity can only grow as Internet access becomes cheaper and more widespread. The swelling market this is producing can be massively exploited if language barriers are also removed.
Following is a proposal for the development of an Internet-based technology that will obviate lingual barriers in e-learning, enabling students to participate in online courses conducted in a foreign language. Should it be realized, adoption of this technology stands to transform both the e-learning business and core concepts of traditional learning. Hence, the scalability potential for such a system is enormous. Online courses already have great appeal. They effectively remove the obstacles, such as time and location, that conventional academic attendance impose.
The Models
The proposed application comes in two versions: the Translation model and the Proofing model.
The value of the Translation model is self-evident: students are able to enroll in courses from any online source, regardless of the language it is taught in. The student can interact with his/her classmates and teacher in his/her own language, regardless of language concerns, and his/her essays, reports, and projects can also be fully translated.
In comparison, the Proofing model may appear a somewhat inferior sibling. This is not the case. In fact, the opposite may be true. Many students want to do a course in English or a foreign language because they desire the collateral benefits of improving or practicing their language skills while learning their chosen subject. The Proofing model provides speakers of English as a second language with a rewriting/checking/polishing service. This allows students whose mother tongue is not English (or another language) to claim rightful prestige from taking a recognized course taught in that language. The Proofing model utilizes the same applications that support the three forms of the Translation model. The Proofing model mirrors the Translation model, but the process is monolingual and monodirectional.
Both models are of highly similar structure and format. Naturally, the Translation model is more complex. The Translation model requires a duplex functionality and bi-directionality, without which both sides would otherwise be effectively blind and incomprehensible to each other. Operationally, the interfaces and therefore the bulk of the code that will drive them are consistent: in the Translation model, an intermediary translates and then forwards messages; in the Proofing model, the same happens, but the translation is from the same language to an improvement of that language.
Implementation into Existing Platforms
Both interfaces described here are based around Blackboard. Ideally they would function seamlessly through Blackboard.
Blackboard is a commonly employed online teaching platform that, due to its usability and general simplicity of management, is recognized and heavily endorsed by many, if not most, institutions running online courses. Blackboard works almost exactly like a discussion group/message board, but has a few extra features, such as a digital drop-box facility that allows users to “drop” documents or files for retrieval by other users (e.g. student to teacher).
Translation Model
Rationale
For purposes of hypothesis, our course is conducted in English, but some of the students are Japanese. Both teacher and students are monolingual. The Translation model addresses this scenario.
Preliminaries
Bilingual communication requires an intermediary third party. This we will call the Interlator. Let us assume for the time being that the Interlator is a single human being.
Blackboard Discussion Utility
Purpose
To provide translation of presented teaching material and the students’ discussion of that material.
In Brief
The Interlator translates the content of the Blackboard discussion. He/She posts these in Japanese.
On the Japanese students’ screens, discussion appears entirely in Japanese. On the teacher’s and English-speaking students’ screens, discussion is in English only. On the Interlator’s screen, both languages appear.
For normal Blackboard (that is, class discussion group) usage, time is not an issue; so no time scheduling is prescribed – the Interlator can translate and post messages as they appear, or within a limited time period (48 hours, for example).
Interlator’s Screen
The Interlator’s screen consists of three windows: English in/out, Input, and Japanese in/out.
In the English in/out window, the Interlator views the discussion in the original language.
The Interlator clicks on a message in this window. The clicked message then appears in a view pane in the Input window (it cannot be edited here, only viewed). The Interlator enters the equivalent Japanese, and then clicks [Post]. The translated message then appears on the Japanese in/out screen (and is thereafter visible to the Japanese users).
Student’s Screen
The Japanese students view the discussion entirely in Japanese (except where content necessitates otherwise). There is a [Before and After log], which the student can click to view his/her original Japanese and the translations submitted to the discussion by the Interlator.
English speaking students (and the teacher) see the discussion entirely in English.
When a Japanese response comes back, it appears in the Japanese in/out window. The Interlator translates this, and posts it to the English discussion. The Interlator cannot be contacted. For queries regarding wording issues, the user can, for example, select the problem phrase, right click on the mouse, and then select the {}Query this{} or {}Reword{} option. The phrase can then be sent back to the Interlator, or reworded automatically using dictionary database software. The automated solution may be preferable, as the user can reword until he/she finds a satisfactory alternative, and this lessens the Interlator’s workload.
Two separate discussion boards are running in parallel. Only the Interlator sees both. For simplicity’s sake (and to avoid complications caused by mixing of double- and single-byte characters), these discussion boards could be managed on separate server drives. If necessary, the entire Blackboard interface could be in Japanese. This however, is a slightly different concern, but may merit consideration, depending on market potential. Only the Interlator sees both languages. From the user’s perspective, all messages appear in their own language.
The Interlator cannot be contacted. He/She is not available for questions regarding content. The Interlator cannot provide discourse or assistance. Students have to address all mail directly to teachers or classmates. For queries regarding wording issues, the user could, for example, highlight the problem phrase, right click on the mouse, and then select the {}Query this{} or {}Reword{} option from the popup menu that appears. The phrase could then be sent back to the Interlator, or reworded automatically using dictionary database software. The automated solution may be preferable, as the user can reword until he/she finds something satisfactory and lessens the Interlator’s workload. In the event of the Interlator’s not being able to understand something, he/she too can send a {}Reword{} or {}Simplify this{} request to the user.
Blackboard Realtime Classroom Utility
Purpose
To provide translation “on the fly”, enabling students to engage in realtime online exchange.
In Brief
This proposal requires development of a messenger-type utility that is plugged into the typical Blackboard. It offers one-to-class, real time, translation.
For teacher-to-class tuition or discussion with a teacher, administrator, or even a classmate, users access a messenger interface through Blackboard. Students type in and send messages as on any messenger.
However, the Interlator receives every message first, translates it into the appropriate language, and then sends it on to the intended recipient.
Same-language exchanges can be auto-detected and ignored by the Interlator.
Interlator’s Screen
The Interlator’s screen consists basically of three columns. English appears on one side, Japanese on the other. The middle column contains an input area where the translation is entered, and a [Send] button for forwarding the translated message. To perform multiple relays, the Interlator’s three-column screen would be horizontally segmented, each segment representing a dialogue: Japanese on one side, English on the other, Interlator’s input between.
Student’s Screen
Students view all exchange in Japanese. They see only the Interlator’s translations of the messages. From the student’s perspective, communication is entirely in Japanese. Vice versa for the teacher.
The software driving the Interlator’s application automatically determines the recipient of the forwarded message, obtaining this information from the sender’s message.
Multiple pair, single-to-multiple, and multiple-to-multiple communication is possible, but would entail Interlator time and labor costs. Multiple Realtime discussions however, would be extremely taxing for the Interlator, and a single Interlator is unlikely to be sufficient,
The primary function of the Realtime Classroom is to provide translation during scheduled class discussion sessions. Ad hoc monitoring is also possible, but to perform this, the Interlator would have to be on constant standby.
Single student-to-teacher is also possible through the Realtime Classroom, but the teacher’s online time is limited. This is addressed by 3.
Realtime Tutor Utility
Purpose
To provide a student-teacher virtual one-to-one via an online, bi-directional translation system.
In Brief
Uses the same technology as the Blackboard Realtime Classroom utility. The Interlator sits virtually between student and teacher, receiving, then translating, and then sending messages.
The Realtime Tutor system differs from the Blackboard Realtime Classroom and Discussion utilities in that the tutor, and only the tutor, is available for a limited time on predetermined days, by appointment. **SELLING POINT** This would be at additional cost, and requires the student to schedule a personal time slot. The tutor’s available time slots would be selectable using a window on the user’s screen.
Interlator’s Screen
As in 2., the Interlator’s screen consists of three columns. English on one side, Japanese on the other; the middle column contains an input area where the translation is entered, and a [Send] button for forwarding the translated message.
Student’s Screen
Students view all exchange in Japanese. They see only the Interlator’s translations of their messages. From the student’s viewpoint, communication is entirely in Japanese.
User-to-User E-mail
The Interlator handles user-to-user e-mail thus: There is a [Student’s Mail] window on the Interlator’s screen. When opened, this displays any mail waiting to be translated for relay. The Interlator clicks on a message and this then appears in a new window that contains an input panel. The Interlator inputs his/her translation of the e-mail into this, and then clicks [Send]. The e-mail, containing the sender’s address, is then forwarded to the intended recipient. Mail returned to the Japanese student (in English) is processed similarly: Interlator this time translating it into Japanese before it is relayed to the student.
Proofing Model
Note
The Proofing model utilizes essentially the same mechanism that supports the three interactive applications of the translation model. The Proofing model mirrors the Translation model, but the process is monolingual and mono-directional. The intermediary, in this model, is an English language assistant, not a translator. Students selecting this option do not receive or produce any Japanese. They work entirely in English, courtesy of a virtually fulltime language helper who helps them improve their reports and enables them to make real time contributions to online discussions.
Rationale
For purposes of hypothesis, our course is conducted in English, some of the students are Japanese. These students are nominally bilingual, but their proficiency does not meet the requirements of academic English. The Proofing model addresses this scenario.
Preliminaries
Proofing requires an intermediary third party. This we will call the Proofer. Let us assume for the time being that the Proofer is a single human being.
Blackboard Discussion Utility
Purpose
To provide corrected student contribution to teaching material.
In Brief
The Proofer rewrites the Japanese student’s contributions to Blackboard discussion. He / She posts these (in English).
On the Japanese students’ screens, discussion appears entirely in the rewritten English. There is, however, a [Before and After log], which can be used for reference, but is not ‘live’, that is, the student cannot rewrite rewrites. On the teacher’s and English-speaking students’ screens, contributions from the Japanese students appear in rewritten English only. On the Proofer’s screen, both pre- and post-rewrite versions appear.
For normal Blackboard (that is, class discussion group) usage, time is not an issue, so no time scheduling is prescribed – the Proofer can edit / rewrite and post messages as they appear, or within a limited time period (48 hours, for example).
Proofer’s Screen
The Proofer’s screen consists of three windows: Original in, Input, and Rewrite out.
In the Original in window, the Proofer views the Japanese students’ messages in their original English.
The Proofer clicks on a message in this window. The clicked message then appears in a view pane in the Input window (unlike the Translation model, it can be edited here). The Proofer enters the rewrite, and then clicks [Post]. The rewritten message then appears on the Rewrite out screen (and is thereafter visible to all users via the discussion).
Student’s Screen
The student’s screen shows the post-rewrite discussion only. It is identical to the screen seen by all other students and the teacher. This screen differs in only two aspects from the screen of a regular student: there is a [Before and After log] displayed, and there is a delay before the Japanese student’s contribution appears on the discussion board, due to its being diverted to the Proofer for rewriting / checking. The [Before and After log] records the original submission (pre-rewrite) and the amended version (rewrite) for reference purposes. This log is visible only to the submitting student. The post-rewrite screen is the same as that seen by the teacher and all other students.
The Proofer cannot be contacted. He/She is not available for questions regarding content. The Proofer cannot provide discourse or assistance. Students have to address all mail directly to teachers or classmates. The Proofer modifies the English of specified user’s only. He / she does not, for example, reword the contributions of other users. The Proofer cannotbe contacted. For queries regarding wording issues, the user can, for example, select the problem phrase, right click on the mouse, and then select the {}Query this{} or {}Reword{} option. The phrase can then be sent back to the Proofer, or reworded automatically using dictionary database software (available as an extra or built into the Proofer package). The automated solution may be preferable, as the user can reword until he / she finds a satisfactory alternative, and this lessens the Proofer’s workload. The Proofing model utilizes the same applications that support the three forms of the Translation model. The Proofing model mirrors the Translation model exactly, but the process is monolingual and unidirectional (that is, the Proofer modifies only the student’s English, and does not provide rewording of student or teacher messages or any other information).
Only one discussion board is running. However, the Proofer sees the Japanese student’s pre-proofed submissions. The Japanese student does not see his faulty English, only its corrected replacement; other students and the teacher see only the corrected version, and are aware of neither the Proofer’s contribution nor the process behind it.
Blackboard Realtime Classroom Utility
Purpose
To provide language assistance “on the fly”, enabling students to engage in realtime online exchange.
In Brief
This proposal requires development of a messenger-type utility that is plugged into Blackboard. It offers one-to-class, real time, language assistance.
For teacher-to-class tuition or discussion with a teacher, administrator, or even a classmate, users access a messenger interface through Blackboard. Students type in and send messages as on any messenger.
Unlike the Translation Model, proofing is mono-directional. The Japanese user views content in its unmodified, original language (as do all other students and the teacher). However, his contributions are proofed before being forwarded to the Blackboard discussion.
Proofer’s Screen
The Proofer’s screen consists basically of three columns. The original English appears on one side, the student’s faulty contribution on the other; the middle column contains an input area where the proofing is entered, and a [Send] button for forwarding the proofed message. To perform multiple relays, the Proofer’s three-column screen would be horizontally segmented, each segment representing a dialogue: faulty English on one side, perfected English on the other, Proofer’s input between.
Student’s Screen
Students view all exchange in English. They see only the Proofer’s rewrites of their messages.
The software driving the Proofer’s application automatically determines the recipient of the forwarded message, obtaining this information from the sender’s message. Multiple pair, single-to-multiple, and multiple-to-multiple communication is possible, but would entail Proofer time and labor costs (although these would be far less than those of the Translation model). Multiple Realtime discussions however, would be taxing for the Proofer, but a single Proofer may be sufficient. depending on
- the quality of the English he receives,
- the number of students submitting,
- the volume/content of those submissions.,
- and the quality of any automated support applications the Proofer may have at his disposal.
The primary function of the Realtime Classroom is to provide perfected English during scheduled class discussion sessions. Ad hoc monitoring is also possible, but to perform this, the Proofer would have to be on constant standby.
Single student-to-teacher is also possible through the Realtime Classroom, but the teacher’s online time is limited. This is addressed by 3.
Realtime Tutor Utility
Purpose
To provide a student-teacher virtual one-to-one via an online, bi-directional translation system.
In Brief
The online tutor system is a student-teacher virtual one-to-one. It utilizes the same technology as the Blackboard Realtime Classroom utility. The Proofer sits virtually between student and teacher, receiving, then correcting, and then sending on messages. Unlike the Translation model however, the Proofing model Realtime Tutor Utility is not bi-directional: the student receives the teacher’s messages in the original, unmodified English.
The Realtime Tutor system differs from the Blackboard Realtime Classroom and Discussion utilities in that the tutor, and only the tutor, is available for a limited time on predetermined days, by appointment. **SELLING POINT** This would be at additional cost, and requires the student to schedule a personal time slot. The tutor’s available time slots would be selectable using a window on the user’s screen.
Proofer’s Screen
As in 2., the Proofer’s screen would contain three columns. English on one side, Japanese on the other; the middle column contains an input area where the translation is entered, and a [Send] button for forwarding the translated message.
Student’s Screen
Students view all exchange in English. They see only the Proofer’s corrected version of their messages.
User-to-User E-mail
The Proofer handles user-to-user e-mail thus: There is a [Student’s Mail] window on the Proofer’s screen. When opened, this displays any mail waiting to be proofed for relay. The Proofer clicks on a message, and this then appears in a new window that contains an input panel. The Proofer inputs his/her corrected version of the e-mail into this, and then clicks [Send]. The e-mail, containing the sender’s address, is then forwarded to the intended recipient. Mail is returned to the Japanese user directly, and does not go through the Proofer.
Potential Problems
Several factors limit the Realtime applications (2. and 3., both models), and all of these concern time. Speed of relay is explicitly dependent on the factors listed below and is especially problematic when the Interlator / Proofer is contending with multiple dialogues.
Translation Model, Blackboard Realtime Classroom Utility, and Realtime Tutor Utility
The primary benefit (and therefore selling point) of these two applications is their “Realtime” facility, however, delays will occur at the Interlator stage of the process. The severity of these delays is determined by the following:
- complexity of the received Japanese,
- number of students submitting (3. only),
- volume and content of submissions,
- quality of any automated support applications that the Interlator may be using,
- and miscellaneous human variables (Interlator proficiency, student idiosyncrasies, for example).
Proofing model, 2. Blackboard Realtime Classroom Utility and 3. Realtime Tutor Utility
As in the Translation model, the primary benefit and therefore appeal of these two applications is their “Realtime” functionality. The intermediary Proofing stage will however create delays, but in most cases these should be less severe than in the Translation model. The severity of these delays is determined by the following:
- quality of the received English,
- number of students submitting (3. only),
- volume/content of submissions,
- quality of any automated support applications the Proofer may be using,
- and miscellaneous human variables (Proofer proficiency, student idiosyncrasies, for example).
Solutions – Automation
Ideally, the Interlator would be a fully automatic process running from a server (not locally). Currently, no translation packages can provide output that offers anything approaching the robustness required to meet academic standards. However, a small number of supplemental programs may contribute to reducing time loss and generally lightening the Interlator’s / Proofer’s workload:
Terminology Helper
A program that learns and stores frequently occurring terms and phrases particular to the subject. Thus, when the student enters a known term, the English equivalent is automatically selected and transposed into the Japanese. The Interlator has then only to write the grammar around it. This works bilingually, so English submissions generate corresponding Japanese terms that the Interlator then has to organize rather than recall. This program could have a vocabulary insert facility that enables it to incorporate existing specialist digital dictionaries and store these on the server’s hard drive for retrieval as necessary.
Resource Auto-thru
Takes the Proofer/Interlator to a number of online resources, such as wikipedia, translation engines (for purposes of comparison), and so on.
Predictive Text
Helps speed the Interlator’s/Proofer’s inputting.