Re: [Sugar-devel] Multilingual Help activity: which localisation tools (was Re: Potential volunteer offering technical writing)
Hi Bastien, If there are no other voluntier, I can work on packaging the activity with the updated content. Gonzalo On Sat, Oct 15, 2011 at 11:16 AM, Bastien wrote: > Hi all, > > is there any volunteer to take over maintainership of the > XO Help activity? > > http://activities.sugarlabs.org/en-US/sugar/addon/4051 > > As the content is expected to be drastically updated, I > guess it is a good time for someone to step up -- I won't > have time to do the update myself. > > Thanks! > > -- > Bastien > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Multilingual Help activity: which localisation tools (was Re: Potential volunteer offering technical writing)
Hi all, is there any volunteer to take over maintainership of the XO Help activity? http://activities.sugarlabs.org/en-US/sugar/addon/4051 As the content is expected to be drastically updated, I guess it is a good time for someone to step up -- I won't have time to do the update myself. Thanks! -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Multilingual Help activity: which localisation tools (was Re: Potential volunteer offering technical writing)
Hola Gonzalo, Le mercredi 05 octobre 2011 à 17:01 -0300, Gonzalo Odiard a écrit : > In my personal opinion, Pootle is not good for doing a job like this. > And is possible do the translation of a UI piece by piece, but a text > need a > > different conceptual integrity and style. > Your point is very convincing. I agree with you that the tool used should be adequate and contribute to the final quality of a documentation project. Moreover, the fact that the writing process is carried out by a team of people with variable writing skills constitutes an additional factor of risk as quality is concerned. Such projects are challenging, even professional writers. In any case - and the translation project of the manual authored by Sdenka Zobeida Salas Pilco OLPC Frances volunteers have contributed to confirms your own experience - it requires an additional step to harmonize the writing style and the terminology between the different contributors, even in a technical document, which is supposed to be factual and less prone to stylistic variations as with other texts. Kind regards, Samy > Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Multilingual Help activity: which localisation tools (was Re: Potential volunteer offering technical writing)
Hi Samy, May be I can't convince you, but is what I have learn from practice. I only want to point you about two topics: * Fototoon is a good example: the UI have only 16 phrases and 26 words! In part because is a simple activity, and in part because all the Sugar interface is designed to use as little text as possible. In contrast a help page about Fototoon can have a lot of text, and the format, can be easily redone. * I have participated in the translation of "Make your Own activities" to Spanish. Only one chapter, but I saw part of the work involved by the team. The work involved 15 volunteers, many mails with the original author, and the final style review of a professional writer, (and ask permission to the publish house who had the rights of Mark Twain in Spanish) If you are creating a manual for kids, probably you will need recreate the screenshots where there are text too. This is if you want do a good job and not a google translate automatic translation. In my personal opinion, Pootle is not good for doing a job like this. And is possible do the translation of a UI piece by piece, but a text need a different conceptual integrity and style. Gonzalo On Wed, Oct 5, 2011 at 4:26 PM, samy boutayeb wrote: > Hola Gonzalo, > > > > > > We do not have translations in Help Activity. > > And is not a good idea use the same tools/strategies to translate a few > > strings in a activity > > and a full text document. > > > Quoting Martin in a previous post, Id like to say "Yes and no" ;-) > > I agree with you that we have 2 different types of activities. > My point is that, altough we are faced with 2 different cases, it makes > sense to use a common reference (in the form of a so called "translation > memory", which refers to the content" of the activity) and, why not, a > set of common tools designed to manage this content. > > Let's me illustrate my argumentation with the exemple of the FotoToon > activity [1] and of the potential corresponding chapter "Fototoon" of > the Help activity, and in particular from a triple point of view: from > the developer's perspective (which I am not. As you are the developper > of this activity, Gonzalo, please feel free to correct me if my naive > understanding is incorrect), from the translator's/localizer's > perspective (which I happen to be) and from the user's perspective. > > 1/ Developper > * FotoToon Activity: You develop fonctions and commands which should be > executed from a graphical user interface (with UI elements, as buttons, > menus, tooltips, etc. and eventually a help file, both online and > offline. You provide to this end a set of text strings, which are > embedded in your code. > > Examples: "Add Whisper", "Add Box", "Bold", "Save as Image" > * Help Activity: The documentation writer writes a chapter "Fototoon" > dedicated to the corresponding activity "FotoToon". The document > consists of a succession of whole sentences, which refer to the > functions of the "FotoToon" activity and uses to this end : > - simple text > - screenshots (located between chapters) > - names of functions/commands (located in the sentences) > - symbols of the user interface (located in the sentences) > > 2/ Translator/localizer > * FotoToon Activity: You provide the translators/localizers (one for > each target language) a list of translatable text strings (in form of a > po file) which you extract from your code. > Then, each translator provides with the equivalence of your strings in > his respective language: > > Example (French): > 4 Add Whisper Ajouter un chuchotement > 6 Add Box Ajouter un cartouche > 10 BoldGras > 13 Save as Image Enregistrer sous une image > > For this task to be achieved, a "localization tool" has proved to be > efficient, helping to manage a bi-/multilingual localization project, > including various consecutive releases of the activity/program. Here is > the key-word "consistence". > > File type: po file (bilingual text file of strings backed up in a > translation memory) > > * Help Activity: > The document (consisting of chapters) is divided in sentences. Those may > embedd symbols (non editable) and names of functions/commands, which are > localizable and should be consistent with the localized version of the > strings of the "FotoToon" activity, as they refer to the GUI which is > displayed by the user, according to the locale (EN-US, ES-UY, FR-FR, > etc.) selected. > This is where the "translation memory" function is useful, especially if > the localization workflow includes the translation of the names of the > GUI elements. This is not mandatory, then a variant consists in mark the > GUI elements as variables, which are merged later with the content of > the po file. > > File type : (a) text document (either 2 monolingual documents or one > bilingual document in with the sentences are segmented by the > localization tool and backed up in a translation memory). > (b) 2 sets of screensho
Re: [Sugar-devel] Multilingual Help activity: which localisation tools (was Re: Potential volunteer offering technical writing)
On Wed, Oct 5, 2011 at 3:26 PM, samy boutayeb wrote: > Hola Gonzalo, > >> > >> We do not have translations in Help Activity. >> And is not a good idea use the same tools/strategies to translate a few >> strings in a activity >> and a full text document. >> > Quoting Martin in a previous post, Id like to say "Yes and no" ;-) > > I agree with you that we have 2 different types of activities. > My point is that, altough we are faced with 2 different cases, it makes > sense to use a common reference (in the form of a so called "translation > memory", which refers to the content" of the activity) and, why not, a > set of common tools designed to manage this content. > > Let's me illustrate my argumentation with the exemple of the FotoToon > activity [1] and of the potential corresponding chapter "Fototoon" of > the Help activity, and in particular from a triple point of view: from > the developer's perspective (which I am not. As you are the developper > of this activity, Gonzalo, please feel free to correct me if my naive > understanding is incorrect), from the translator's/localizer's > perspective (which I happen to be) and from the user's perspective. > > 1/ Developper > * FotoToon Activity: You develop fonctions and commands which should be > executed from a graphical user interface (with UI elements, as buttons, > menus, tooltips, etc. and eventually a help file, both online and > offline. You provide to this end a set of text strings, which are > embedded in your code. > > Examples: "Add Whisper", "Add Box", "Bold", "Save as Image" > * Help Activity: The documentation writer writes a chapter "Fototoon" > dedicated to the corresponding activity "FotoToon". The document > consists of a succession of whole sentences, which refer to the > functions of the "FotoToon" activity and uses to this end : > - simple text > - screenshots (located between chapters) > - names of functions/commands (located in the sentences) > - symbols of the user interface (located in the sentences) > > 2/ Translator/localizer > * FotoToon Activity: You provide the translators/localizers (one for > each target language) a list of translatable text strings (in form of a > po file) which you extract from your code. > Then, each translator provides with the equivalence of your strings in > his respective language: > > Example (French): > 4 Add Whisper Ajouter un chuchotement > 6 Add Box Ajouter un cartouche > 10 Bold Gras > 13 Save as Image Enregistrer sous une image > > For this task to be achieved, a "localization tool" has proved to be > efficient, helping to manage a bi-/multilingual localization project, > including various consecutive releases of the activity/program. Here is > the key-word "consistence". > > File type: po file (bilingual text file of strings backed up in a > translation memory) > > * Help Activity: > The document (consisting of chapters) is divided in sentences. Those may > embedd symbols (non editable) and names of functions/commands, which are > localizable and should be consistent with the localized version of the > strings of the "FotoToon" activity, as they refer to the GUI which is > displayed by the user, according to the locale (EN-US, ES-UY, FR-FR, > etc.) selected. > This is where the "translation memory" function is useful, especially if > the localization workflow includes the translation of the names of the > GUI elements. This is not mandatory, then a variant consists in mark the > GUI elements as variables, which are merged later with the content of > the po file. > > File type : (a) text document (either 2 monolingual documents or one > bilingual document in with the sentences are segmented by the > localization tool and backed up in a translation memory). > (b) 2 sets of screenshots (one for each language) > > 3/ User > * FotoToon Activity: The user "plays" with the "FotoToon" activity in > the language set at the system level. > * Help Activity: The user reads/searchs/browses the Help activity in the > language selected. The screenshots and the names of the functions should > match the GUI displayed. > > My conclusion: altough the standard activities and the Help activities > have distinct use cases (for the developer, the translator/localizer and > the user), and use different contents (single strings versus complete > sentences plus screenshots and symbols), from the localization point of > view, it makes sense to use a common localization tool and a common > "translation memory" in order to achieve a consistent experience for the > developer, the localizer and the user. > The fact that actual localization tools are able to manage efficiently > those different contents speaks in favor of a sigle translation memory > and, for the sake of simplicity, of a single localization tool. I am in agreement with many of the challenges (and opportunities) that Samy raises. To provide a specific example, we host the WavePlace lesson plans for learning with e
[Sugar-devel] Multilingual Help activity: which localisation tools (was Re: Potential volunteer offering technical writing)
Hola Gonzalo, > > > We do not have translations in Help Activity. > And is not a good idea use the same tools/strategies to translate a few > strings in a activity > and a full text document. > Quoting Martin in a previous post, Id like to say "Yes and no" ;-) I agree with you that we have 2 different types of activities. My point is that, altough we are faced with 2 different cases, it makes sense to use a common reference (in the form of a so called "translation memory", which refers to the content" of the activity) and, why not, a set of common tools designed to manage this content. Let's me illustrate my argumentation with the exemple of the FotoToon activity [1] and of the potential corresponding chapter "Fototoon" of the Help activity, and in particular from a triple point of view: from the developer's perspective (which I am not. As you are the developper of this activity, Gonzalo, please feel free to correct me if my naive understanding is incorrect), from the translator's/localizer's perspective (which I happen to be) and from the user's perspective. 1/ Developper * FotoToon Activity: You develop fonctions and commands which should be executed from a graphical user interface (with UI elements, as buttons, menus, tooltips, etc. and eventually a help file, both online and offline. You provide to this end a set of text strings, which are embedded in your code. Examples: "Add Whisper", "Add Box", "Bold", "Save as Image" * Help Activity: The documentation writer writes a chapter "Fototoon" dedicated to the corresponding activity "FotoToon". The document consists of a succession of whole sentences, which refer to the functions of the "FotoToon" activity and uses to this end : - simple text - screenshots (located between chapters) - names of functions/commands (located in the sentences) - symbols of the user interface (located in the sentences) 2/ Translator/localizer * FotoToon Activity: You provide the translators/localizers (one for each target language) a list of translatable text strings (in form of a po file) which you extract from your code. Then, each translator provides with the equivalence of your strings in his respective language: Example (French): 4 Add Whisper Ajouter un chuchotement 6 Add Box Ajouter un cartouche 10 BoldGras 13 Save as Image Enregistrer sous une image For this task to be achieved, a "localization tool" has proved to be efficient, helping to manage a bi-/multilingual localization project, including various consecutive releases of the activity/program. Here is the key-word "consistence". File type: po file (bilingual text file of strings backed up in a translation memory) * Help Activity: The document (consisting of chapters) is divided in sentences. Those may embedd symbols (non editable) and names of functions/commands, which are localizable and should be consistent with the localized version of the strings of the "FotoToon" activity, as they refer to the GUI which is displayed by the user, according to the locale (EN-US, ES-UY, FR-FR, etc.) selected. This is where the "translation memory" function is useful, especially if the localization workflow includes the translation of the names of the GUI elements. This is not mandatory, then a variant consists in mark the GUI elements as variables, which are merged later with the content of the po file. File type : (a) text document (either 2 monolingual documents or one bilingual document in with the sentences are segmented by the localization tool and backed up in a translation memory). (b) 2 sets of screenshots (one for each language) 3/ User * FotoToon Activity: The user "plays" with the "FotoToon" activity in the language set at the system level. * Help Activity: The user reads/searchs/browses the Help activity in the language selected. The screenshots and the names of the functions should match the GUI displayed. My conclusion: altough the standard activities and the Help activities have distinct use cases (for the developer, the translator/localizer and the user), and use different contents (single strings versus complete sentences plus screenshots and symbols), from the localization point of view, it makes sense to use a common localization tool and a common "translation memory" in order to achieve a consistent experience for the developer, the localizer and the user. The fact that actual localization tools are able to manage efficiently those different contents speaks in favor of a sigle translation memory and, for the sake of simplicity, of a single localization tool. Kind regards, Samy > Include multiple languages in the Help activity does not scale. > > We can use get-books/pathagar to resolve the multiple languages and the > infinite storage problem. > > I think the first problem is have the updated manuals, and can be done in a > few days by a group of volunteers. > > Gonzalo > [1] http://activities.sugarlabs.org/fr/sugar/addon/4253 [2] [3] http
