In MyRobotLab you can set the Locale for all services in the Runtime service panel. Or in Python with runtime.setLocale(code)  where code is "en-US, fr, it-IT or any valid locale code.

MyRobotLab, we support having different translations for certain info , error, and status types of messages in myrobotlab.

  • Language specific strings are stored per service by default in the resource/ServiceType/localization directory.  (replace "ServiceType" with the type of service InMoov2 for example.
  • The files with the localized (translated) strings will be in standard java properties format.  key=value (one per line, with comments starting with a # sign.)
  • The 2 digit language code is used for the language specific filenames.   for example:  en.properties, or fr.properties


     

  • Runtime defines the locale / language for MyRobotLab.  Example:  runtime.setLocale("en-US")
  • Looking up the string will be using the "localize" method on services.  Example:  i01.localize("BATTERYLEVEL") There is only a single localization file per language. These will all be consolidated into a single file named   "en.properties"  in the resource/InMoov2/localization folder.


     

  • If a translated label isn't found on the service, it will fallback to see if there's a match for that label defined for the Runtime service.
  • If a language specific match for the label can't be found, we will fallback and return the english localized version (and potentailly we should log a message asking someone to help us translate that label.)

In Python:

i01.mouth.speak(str(Runtime.getBatteryLevel())+i01.localize("BATTERYLEVEL"))

And that would look up the string to use for "BATTERYLEVEL" in the current language (locale) that the bot is set to operate in.

Matching Precidence could/should be as follows:

  • Match Service with current Locale of the Runtime service
  • Match Service with Default (english) Locale
  • Match Runtime with current Locale of the Runtime service.
  • Match Runtime with Default (english) Locale

Some additional comments about the keys used in the properties files.. they should be:

  • alpha numeric only.
  • no white space characters
  • case insensitive
  • should not contain an equals sign in the key
  • generally, easy to read/understand as a human

Example  /resource/Runtime/localization/en.propreties

Runtime.setAllLocales('en')  will set all running services Locales to the new value.

When MRL starts I had Runtime.setLocale('fr') - all subsequent services will default to the same locale value.

While the filter is running I can Runtime.setAllLocales('es') and all (including OpenCV) locales will switch.

hairygael

4 years 6 months ago

After a git pull on webgui_work branch and using the myrobotlab.jar #79

Mmmh,

Runtime.setLocale('fr')

ERROR c.myrobotlab.framework.Service - python error Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: setLocale(): expected 2 args; got 1

re-Mmmh:

Runtime.setAllLocales('en')

ERROR c.myrobotlab.framework.Service - python error Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: setAllLocales(): expected 2 args; got 1

All I am trying to do is fix what was previously working in Manticore before the refactor of languagePack:

https://github.com/MyRobotLab/InMoov2/blob/master/resource/InMoov2/system/ConfigParser.py#L46

if not Runtime.setAllLocales('Language'):
  languageError=True
  Runtime.setAllLocales('en')

I also noticed that localize needs a localize version for everything.

If in the scripts I have:

errorSpokenFunc('ARDUINONOTCONNECTED',Port)

It spoke:

ARDUINONOTCONNECTED=I have a problem with the port com of the arduino

Port=COM3

Now with refactor it speaks:

ARDUINONOTCONNECTED=I have a problem with the port com of the arduino

Port=Not yet translated

please help us get a good translation for COM3 in en-US

Your not using the latest jar.

I tested both the latest on develop, and webgui_work - both produce the same results
http://build.myrobotlab.org:8080/job/myrobotlab/job/develop/
http://build.myrobotlab.org:8080/job/myrobotlab/view/change-requests/job/PR-677/

#145 or #81 respectively

I have no idea how you are running ConfigParser.py - you didn't say.  Is this through bat files vs webgui ?
I can be more helpful if I can reproduce the same result using the same steps to get there...

I ran 
./start_inmoov.sh

and got different results .. :(

I spent a while looking into this .. and the problem when I ran the script, is it started InMoov not InMoov2 .. so there is no localization information in InMoov - I migrated all the data over to InMoov2

Hello Grog,

Sorry if I wasn't clear enough. I do use the latest available after a git pull and downloading the latest #677

But as explained on the shoubox yesterday, it is a bit challenging to use InMoov2 in dev/myrobotlab because many scripts should be located in dev/myrobotlab/resource/InMoov2 to properly test, while they are located in dev/InMoov2//resource/InMoov2

I use START_INMOOV2.bat or the button "load system" on the InMoov webgui.

Both launch InMoov2.py which then runs InitCheckup.py which runs ConfigParser.py.

ConfigParser.py had i01.setLanguage but I changed that to Runtime.setAllLocales

https://github.com/MyRobotLab/InMoov2/blob/master/resource/InMoov2/system/ConfigParser.py#L46

if not Runtime.setAllLocales('Language'):
  languageError=True
  Runtime.setAllLocales('en')

The only thing I try to do is fix what was worky with languagePack, it seems there is some kind of issue with re locating or re localizing if you prefer...

On another topic, do you think we should make a develop InMoov2 branch because I noticed some files that you pushed which shouldn't be in the master branch. I happened to find in the InMoov2 bots some default.predicates,  greg.predicates and some harry directory, I removed them, but I might not be always around to check.

 

Hi Gael,

But as explained on the shoubox yesterday, it is a bit challenging to use InMoov2 in dev/myrobotlab because many scripts should be located in dev/myrobotlab/resource/InMoov2 to properly test, while they are located in dev/InMoov2//resource/InMoov2

I use START_INMOOV2.bat or the button "load system" on the InMoov webgui.

Both launch InMoov2.py which then runs InitCheckup.py which runs ConfigParser.py.

ConfigParser.py had i01.setLanguage but I changed that to Runtime.setAllLocales

Yes, I went further and updated all of webgui to use the execScript, then found that scripts within reference other scripts with a path that is not expected for develop time. Of course I did not commit or check in, but I did see the problem.

In a way its good that we are seeing this, because I think its the last big alignment that needs to be worked out.

Let me try to explain some of the design going forward and then you can understand.
From nearly the beginning of MyRobotLab 10 years ago I wanted the software to be a "pluggable framework".
This means other developers can create services that will work with the framework and other services as long as they conform to a set of rules.   The analogy fits with Legos - in that developers can make any crazy cool lego they want as long as the pluggable part follows some specific dimensions.

All previous versions of myrobotlab had everything checked in to myrobotlab repo - and had to go through the singular process of getting all built together.  In this process - everyone would need to submit their designs and only a single company could build the legos. In Nixie, I have (after considerable work) reversed this requirement.  

ProgramAB and InMoov are (nearly) independent services. You and Astro have developed on these repos without the need (mostly) of myrobotlab.jar builds.  I've also created an easy to maintain oven (ci/cd jenkins process) which auto-magically puts all the pieces together regardless of which repo gets updated.

Parallel development can be very difficult to do correctly, but when it works the benefits are very large. 

The rules to keep legos fitting together are:

  • Services which are independent should keep all their resources together in their own repo.
  • Their directory structure needs to be repo {ServiceType}/resource/{ServiceType/..
  • If all independent services and myrobotlab is checked out to the same level, they all work without copying stuff from one place to another.  This is how make_web_dev.bat works
  • All old services still work with their resources the way they are currently checked into myrobotlab

The InMoov2 scripts are considering only "run time" not "develop time".  I wish the structure was the same in "run time" as "develop time", but it isn't, and there are things outside of my control which make it this way   

execScript I made to hide the complexity and make it easier for developers.  It will grab the correct script because it senses which environment its in (runtime/devtime).  

I can help fix all the scripts, but plan at the moment is to first get Servo webgui working better than swinggui.

Additionally I want to add pytest (Python's automatic testing elves) so that once it finally aligns, there will be elves checking it on every build.

Hope this gives you a better view.  I think its important we align closely.  We do not want to do this again.

I'm excited you have gotten involved in the Intro and WebGui.  Its our opportunity to align and it will be a better user experience in the long run.

On another topic, do you think we should make a develop InMoov2 branch because I noticed some files that you pushed which shouldn't be in the master branch. I happened to find in the InMoov2 bots some default.predicates,  greg.predicates and some harry directory, I removed them, but I might not be always around to check.

No.  develop branch after Nixie will be going away - there will only be feature branches and "master".  This is the correct way to use git.  

Here is details if you want - https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

The correct way to fix this probably is with .gitignore

 

Hello grog,

Wow long answer!

Thanks Grog for all the explanations which helps to see the future more clearly.

Since I am a kid I love lego!!

I was not asking you to fix the scripts though. I am trying to fix them, but if things aren't worky in java or modified, it can take me hours trying to fix what is not fixable via python. This was the reason I posted the explanations because since localize has been set up speakBlocking is now borked in InMoov2.

I have sent a noworky just in case.

Service.java:1646] could not invoke i01.speakBlocking ([Starting mouth])
java.lang.reflect.InvocationTargetException: null
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_252]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_252]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_252]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_252]
    at org.myrobotlab.framework.Service.invokeOn(Service.java:1642) [myrobotlab-1.1.89.jar:1.1.89]
    at org.myrobotlab.framework.Service.invokePeer(Service.java:2055) [myrobotlab-1.1.89.jar:1.1.89]
    at org.myrobotlab.service.InMoov2.speakBlocking(InMoov2.java:1196) [myrobotlab-1.1.89.jar:1.1.89]
    at org.myrobotlab.service.InMoov2.speakBlocking(InMoov2.java:1176) [myrobotlab-1.1.89.jar:1.1.89]
    at org.myrobotlab.service.InMoov2.startMouth(InMoov2.java:1508) [myrobotlab-1.1.89.jar:1.1.89]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0

Localize currently borked some things in InMoov2 which were working last week and it didn't solve language Pack removal from InMoov.java

Anyway, in a few days I will not have anymore time to try to solve things because I have to work again and its going to be difficult to find free time.