Click on one of these to start Geogebra Translator in Version 5.0. Different builds of GGB are available:
GGB builds generated by GitHub Actions are available as releases in this repository.
The translator starts as a Geogebra page. To obtain a multilingual version of SomeName.ggb file one has to give the two letter code XY of the original language (e.g. EN). You can set a string for the Translator Version. TRN001 is the default. Another option is TRN003 that sometimes is useful when you do not want ot flat lists. Another option is TRN004 that prevents from flattening objects with commands. Then click the button "Export Translation". Then a file picker comes up and you can select one or more files SomeName.ggb.
The service promt to download SomeName-FL-XY.html and SomeName-FL.ggb. Next you have to translate all the strings in the file SomeName-FL-XY.html with some automatic translation system (this one can do the job. For an alternative see this process.). Let assume that we want to have the XZ and YZ version too. So we have to prepare SomeName-FL-XZ.html and SomeName-FL-YZ.html. You can do this by hand using the Notepad++ editor (archived here) with the XML Tools installed (archived here). In the menu Plugins>XML Tools select "pretty print - indent attributes", do your modifications and then in the same menu choose "linearize" and save.
Now you can build your multi-language version of your GGB activity SomeName.ggb. Simply press the button "Import Translations" and in the file picker select SomeName-FL.ggb. SomeName-FL-XY.html SomeName-FL-XZ.html and SomeName-FL-YZ.html. If in the first step you asked to process more than one file then in this step you must provide all the generated and translated files.
The system will output and ask you to download file SomeName-FL-XY-XZ-YZ.ggb. Loading this in GGB will give you the original SomeName.ggb decorated with an additional button LNG that you can use to switch the language of the exercise.
You can find an example of the resulting GGB activity here that is taken from this site. The multilingual GGB activity will have name SomeName-FL-XY-XZ-YZ.ggb where the language codes XY-XZ-YZ are reordered alphabetically. In the GGB document, to be fair, the buttons are reordered in an inverse alphabetical orderer but the original language button always comes last.
In some framework (e.g. Moodle question
banks), turning on automatic translation within your browser can do
the trick and present acceptable translation of school activities.
With Geogebra this will not work. Furthermore, in many occasions,
translating a Geogebra activity require to get some grasp upon the
developer logic and very often, if you are not the developer, to build a
new activity from the scratch is easier than translating an existing one.
This package tries to do its best to extract all textual elements from an
activity, feed them through an online translator, record the translation
and build some persistent machinery, in the Geogebra ggb document. The
goal is to record the two or more linguistic versions of an activity
within a single ggb file. This ggb, then can then be shipped as a
standalone classroom activity.
This tool does not try to generate automatically a translation using an
online translation. This tool produce an HTML list of all the strings that
needs translation. The user can translate this document by hand or by
feeding it thru some online translation facility. The translated HTML will
then be automatically linked within a multi-lingual ggb activity.
This package handles multi-language ggb supporting several languages
within a single ggb document. This package can, somehow, follow the
development process. For instance, the teacher, having slightly
changed the logic of an activity, keeping all the textual parts unchanged,
has the option to rebuild the multilingual ggb without repeating all the
process. On the other hand if some strings are changed the process must
update strings only in a particular language and then ask to some online
translator, for an update of all the other translations.Then a new
build is required. The same is for adding a new language.
Some translation string might not fit nicely. You can see where the problem is and try a quick fix directly in the ggb file. The user can find the translated strings in the Algebra view as Geogebra Text Auxiliary objects with special names following the pattern ZZ000<languageCode><originalObjectName>.
Therefore, for instance, if your .ggb contains a button named
```BoutonOui``` with caption "Oui" you will find in the Algebra View the
strings `ZZ000frBoutonOui` with value "Oui" but also `ZZ000itBoutonOui`
with value "Si" and `ZZ000enBoutonOui` with value "Yes". If you are not
satisfied with this you can edit these strings and changes will be
reflected in your Geogebra activity (e.g. you can put "Yeah!" into
```ZZ000enBoutonOui```). If you save the file with the result of your work
you will have a version of your activity that will preserve the fixes you
worked out.
This .ggb it is ready to receive modified translations, too. If you modify
the logic of the activity and ask for revising an already worked out
translation the existing translation strings are not recomputed and only
newly introduced untranslated objects are translated and
inserted. If you delete a translation string
`ZZ000enBoutonOui` the relative object will be considered as
untranslated and generated again the first time you ask to merge an `EN`
translation.
So, if you operate a single language .ggt you can safely delete all
the `ZZ000<languagexx><originalObjectName>` strings in the
Algebra view if you are not interested in language "xx" anymore. This will
make the ggb document more compact and responsive.
The translator tool works only in the Geogebra web version some problems might come from security limitations of the browser. You can circumvent it by running the Geogebra applet in Chrome with the option `--disable-site-isolation-trials --disable-web-security` e.g. in Windows
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-site-isolation-trials --disable-web-security --user-data-dir="I:\temp"
For Chrome you might try also --disable-web-security --allow-no-sandbox-job --allow-sandbox-debugging --no-sandbox --no-sandbox-and-elevated --no-zygote --no-zygote-sandbox --run-without-sandbox-for-testing --disable-popup-blocking --user-data-dir="I:\temp" they could help.
The file index<somename>.html loads the GGB application and the GGB activity `transMulti.ggb` into a GGB Applet that runs in a browser. Loading could be slow. While debugging you can re-initialize the translator from the GGB File menu by reloading the `transMulti.ggb` file.
There is a central selected place in this JS code where, even the un-experienced programmer, can do some editing to make the translator comply with a known style used in textual elements for a set of known ggb activities. This configuration parameters are strings that are found either in the context of function calls or as assignments to variables in the file Init.js . So in the following we list all possible configuration options referring them either as function call parameter or as expression in assignment. You can find them with some comments in the file Init.js
To understand the possible tuning operations one has to consider the fact that this process works in two steps. The first step locates what must be translated. The second step takes several translations and apply them. Troubles in the first step comes mainly from the fact that something that must not be translated is fed to the translator, the obvious example being LaTeX commands (e.g. \text) that are ubiquitous in GGB activities and should NOT become \texte or whatever. There are a number of ways to get this. Let's step thru the code to configure this in Init.js
The list in the call to updateDictionary contains the strings that need no translation. They will remain as they are if they are EXACTLY occurring as strings in GGB activities. If you put there e.g. "XYZ" then also \text{XYZ} "'XYZ", " XYZ " will pass untranslated. Simply add the string you do not want to be translated in this list...
updateDictionary(["\\text{", "}","{"...])
In Init,js There are also a pair of initialization that helps the software to parse LaTeX code. Note that a complete LaTeX parser (if ever available in Javascript) is not going to be of great help because, very often, GGB activity creators mix textual content and fragments of LaTeX code to be assembled in a complete LaTeX expression as the activity proceeds. The dictionary dict initialized by another list like...:
var dict = new Map( [ ["text",1],["bar",1],...])
that contains as keys the Latex commands with the number of required parameters. This structure "dict" is a map and keys can also be regexp. The line
["text",1],["end",-1],["textcolor",[false,true]]states that \text has one parameter, \end has one parameter that do not need translation and \textcolor has two parameters and the first do not need translation. The system recognize latex command on the ground of the dictionary initialized by:
updateLatexPatterns([
'\\\\cr','\\\\\\\\',
'\\\\;','\\\\,',
'\\\\left\\(','\\\\right\\)',
...
'\\\\left','\\\\right',
'\\\\[a-zA-Z]{2,}',
'\\\\[^a-zA-Z]',
'\\\\[^\\{|^\\s|^\\\\]*'
]);
that is pretty complete. Note that prefixes
like '\\\\left' comes before the longer match '\\\\left\\['.
Running the first step and consulting the html output you can add strings
you will find in the html file if you know that they do not need
translation. You must add them to the call to updateDictionary.
Finally note that pressing F12 in the browser console you can see the
translator debug messages and draw some ideas on how to adapt the
translator to your style..
In the second step problems can only come from the external translator and
you can solve them simply revising the html file returned by the
translator before applying it. Very often you will find recurring problems
like "Dernier exercice" being translated as "Last fiscal year" and so on.
You can enforce that every time from FR to EN "Dernier exercice" is
translated into "Last fiscal year" you will have "Last exercise". You can
obtain this by modifying the code in the function definition for
initFalsePair. More pricesely you must add a couple in the second
parameter of the call to updateFalsePair(XX,[..]) where XX is the target
language. For instance adding a line like:
function initFalsePair() {
updateFalsePair("EN", ....
["Dernierexercice","Last exercise"],
will ignore the translation in the ...-FL-XX_EN.html for the key Derniereexercice and put there "Last exercise". You can find the actual key Derniereexercice in the file ...-FL-XX_EN.html since there it will be like this
<div id="texte40ovalboxArg1textArg1" data-title="Dernierexercice" class="noop">Last fiscal year</div>
The key Derniereexercice is based on the original text and therefore this will apply probably to other similar situations in other activities in French. Please note that the false pair is stored in a JS map and therefore in the initialization you can use a regexp as a key i.e. /Derniere[s]?exercice[s]?/ instead of "Derniereexercice" and match also the four keys Dernieresexercices, Dernieresexercice etc.
This project was developed and maintained using Eclipse and Egit. Not all the files have a clear meaning. The repository is undoubtedly messy. Nevertheless the repository contains all files generated by Eclipse. By forking this in GitHub and by cloning your fork directly from GitHub into Eclipse with a Egit clone operation you will get an Eclipse project to modify and develop this package on your own. If you feel that later on you can cooperate with us branch your project locally this will make your contribution later submit-able as a pull request. The `.launch` files you will find in this repo must be imported into Eclipse separately to get debug configurations.