Translating Menus

[petabyte]

A while ago I made a proof of concept patch for a Spanish translation of Magic Lantern.
Today I converted it to a module that should work on all versions of ML.

Here it is: https://github.com/petabyt/mlt

Of course, it's very unfinished and unpolished, but I think this could be useful.

[theBilalFakhouri]

Cool!

I compiled it in crop_rec_4k branch, enabled it, ML menus were empty, it didn't work properly

I didn't change anything, tested on 700D

[petabyte]

I assumed you copied the `mlt_es` file into the ML folder and renamed it as `es`?
Although If the menus were empty, then it's a bug, since it shouldn't do
anything if there is no file. Could you possibly send me a ROM dump for debugging?

[theBilalFakhouri]

Oh, I didn't copy "mlt_es" to ML folder, after coping it and renaming it to "es" it worked, cool!
Yeah, without "es" in ML folder the menus are empty, I will PM you the ROMs for 700D.

It seems ML can't handle Arabic characters, not sure how to add support for it, maybe we should use another text encoding system/library? (I have no experience with these)

[names_are_hard]

It's cool seeing the menus in a different language, definitely a good feature to have!  Longer term it might be better to have this in the main code, not a module?  I'm not sure, there are pros and cons.  I suspect it makes most sense that the strings aren't in *any* language in the main code, but instead are referenced by index.  Then you can swap languages in and out easily, by having multiple arrays of strings, one per language, and printing by index.  This is more work but more generic.

Re Arabic characters, kitor did some good work allowing loading fonts from card.  We needed this for modern digic because those cams don't have a bitmap font in rom.  I wrote some scripts that allow converting existing BDF fonts into the Canon format.  So there's a route there that could work.  For the modern cams, they have hardware accelerated font display, using some scalable font format (TTF?  Not sure, some standard, vector format).  These are in roms and likely have many languages (it's what normal Canon menus use), but a) old cams don't have this and b) we don't know how to draw with this yet (looks fairly easy, not tried it).

[petabyte]

> Longer term it might be better to have this in the main code, not a module?
So that would require changing all of the menus? Sounds like a ton of work.

[names_are_hard]

It would be a fair amount of work, but localisation tends to be.  With how you have it currently, if anyone changes the english menu text, your match might break, and then it won't display correctly, right?

[petabyte]

Yeah, whenever a string is changed, MLT won't change anything. I've had some ideas
on how I could make it less frequent, but it's definitely an unavoidable issue. Honestly, having
a few untranslated strings here and there doesn't seem like it would be that bad.

Do you have any idea on how often a menu string is changed?

[names_are_hard]

Changes are surely very rare   I think the way you're doing things will work well in practice.

I do think it would be cleaner if the module only contained the strings for the language, perhaps in an array.  You could have it so every language is a module, including english.  Default build would include english (and I guess language modules would need to be exempt from the "modules don't load if you crashed" logic; or, keep english non-module and it would revert to english if modules didn't load).  Add other modules if you want.  Have a ML menu to swap languages.  Change the main code something like this:

Old code:

Code Select Expand


bmp_printf( FONT_SMALL, 0, y, "Config: %x", (unsigned) global_config );


New equivalent:

Code Select Expand


bmp_printf_localised( FONT_SMALL, 0, y, LOCALISED_CONFIG, (unsigned) global_config );


bmp_printf_localised() looks up the string by the index in the array (LOCALISED_CONFIG would be the index in the array of "Config: %x" in the english array).  That gets passed to bmp_printf().  It's not a hard change, although it is a lot of small changes.

[petabyte]

With a few Python scripts and Google Docs Translate, I was easily able to get several different languages working with MLT.
https://github.com/petabyt/mlt/releases/tag/0.1-more

These were done entirely by Google translate and received hardly any manual review, so feel free to suggest any changes.

Eventually, it may not be a bad idea to pack all languages into a single module. (each language is only 30-40kb)

[Walter Schulz]

Does ML font support german umlauts (ä, ö, ü) and "sharp s" (ß)?

[petabyte]

Not right now, but If I remember correctly, I was able to get some custom Unicode characters working
with https://chdk.setepontos.com/index.php?topic=12813.0

[Walter Schulz]

They are missing right now (replaced by just a, o, u characters) and I'm asking what to do about it:
Nothing?
Replace ä, ö, ü, ß by ae, oe, ue, ss (old ANSI-7 compatible substitution)?
Place "correct" characters which might be not be displayed correctly?

Similar Q for french, spanisch ...

[petabyte]

I had just used the python3 unidecode package to fix the characters.
It looks like they have a reason for this, see https://pypi.org/project/Unidecode/ section "German umlauts are transliterated incorrectly"

For now, I'm think I'm just going to leave them as regular ASCII.
Here's the translated Google Doc: https://docs.google.com/document/d/12txrdFAE401KNcIKUeSYorWbLPK-fVQg9ILj_HRBrME/edit

It might be possible to get my alternative font rendering backend test to work with German characters (see https://github.com/petabyt/mlt/tree/mcufont).
It doesn't seem to show them out of the box, but the Spanish accent characters work:



It could also possibly be used to show Chinese characters too.

[petabyte]

Here are a few German characters working:

[petabyte]

Chinese:

[kitor]

It might be possible to get my alternative font rendering backend test to work with German characters (see https://github.com/petabyt/mlt/tree/mcufont).

On our repo I implemented loading bitmap font (Canon format) from card. We had to do it anyway as new generations (Digic 7+, possibly 6 too) moved to TTF, and ML code expects Canon font to be always available.
https://github.com/reticulatedpines/magiclantern_simplified/commit/05a99a7c5f4c0723568382f629bb8b44a89dd7bb
https://github.com/reticulatedpines/magiclantern_simplified/commit/d024a2e23847ef3ee7157f04f43518a73f8990d6

I think this is worth discussing to go in one direction instead of having more font backends - as there are two already (Canon and RBF)

[names_are_hard]

Also see these tools I made for converting BDF format fonts to Canon format: https://github.com/reticulatedpines/magiclantern_simplified/tree/dev/contrib/font_tools
There are several freely available BDF fonts with permissive licenses (some including extended Roman and/or non-Roman character sets).

Petabyte, it looks like your mcufont repo has a license violation re the Bitstream fonts as you modify their files and the license says you can't do that if you keep the font names.  Easy enough to fix, change the font names.

[petabyte]

Thanks for letting me know names_are_hard, fixed.

Also, note that the mcufont backend is entirely experimental and disabled by default.
I'm 100% open to removing it in favor of something else.

[g3gg0]

cool, like that one

[petabyte]

- Make English an option
- Applied some community patches to language files

`mlt-mcu.mo`: All translations with MCUfont as a text rendering backend. Can write some Unicode characters. You will need to rename it to "mlt.mo".

https://github.com/petabyt/mlt/releases/tag/0.3