#Operation Localization

3 messages · Page 1 of 1 (latest)

snow current
#

Hello everyone, I'm Citty and am in into this nonsense way over my head. Partially to screw with @remote fossil but properly, but mostly to try to extend the reach and comfort of having people interact with a educational device like the Flipper Zero, I think that a localization service is long overdue.

So far, I have a few ideas about how this could be done, none of them feel like perfect solutions to me as of yet.

Currently (potentially overly idealized) goals:

  1. en_US is the current default language of the flipper, and I'd like this to be as performant as possible. I think that this could be reduced to a constant lookup by using a bit of macro magic

  2. I'd like it to be as easy as possible for languages to be added, both inside and outside of the firmware tree. Most translators aren't programmers, and some languages might not end up in OFW ever.

  3. I'd like to avoid filling up all of flash or RAM with localized strings.

  4. Localization should be available to app and animation authors as much as to developers in the firmware tree.

#

Obvious restrictions set by this goal set:

  1. All non en_US languages will likely have to be loaded from SD
  2. Applications will have to be offered an API to add translations at runtime or the ability to add them as a resource
  3. Animation format will likely need modified to allow for this. This change shouldn't be breaking.
  4. Localization format shouldn't be strict. Localizations shouldn't be required to localize every string in firmware, and should gracefully fall back to either en_US or a localization key.
snow current
#

Implementing this as a hash map in RAM was my first idea. This would provide for a lot of flexibility in the system, at the cost of every localized string for the current language being stored in RAM.

Second, en_US could get special treatment as a key value table in flash, and other languages could require a binary search over or access from some other data structure stored solely on SD. This is the least flexible approach, and the localization service would have to keep track of multiple backing providers if we want external assets to be able to provide localizations