Modular localization

  • 3 Replies
  • 557 Views
Modular localization
« on: 18 / June / 2017, 15:55:53 »
Advertisements
As promised, here's a design proposal for modular localization.

Edit 2017-06-19: Replaced moduleName with moduleType for backwards compatibility and moved to wiki.
« Last Edit: 19 / June / 2017, 15:20:12 by dmitrys »
Author of CHIMP, Canon Hack Installation and Management Platform

Re: Modular localization
« Reply #1 on: 19 / June / 2017, 15:24:13 »
I really tried BBcode-formatting the proposal, but Simple Machines revolted.

The updated proposal resides here.
Author of CHIMP, Canon Hack Installation and Management Platform

*

Offline philmoz

  • *****
  • 3060
    • Photos
Re: Modular localization
« Reply #2 on: 21 / June / 2017, 04:33:17 »
I really tried BBcode-formatting the proposal, but Simple Machines revolted.

The updated proposal resides here.

If you think you can make it work then go for it, based on my knowledge of the module system I think you will face some challenges - especially steps 7, 8 & 9.

Some general thoughts:
- I don't understand why UID's 1 - 4 are reserved for module type.
- Limiting the system to 64 modules MAXIMUM over the lifetime of CHDK seems likely to come back to haunt future developers. Why not 99?. Or use hex values for XX and allow 255?
- There is no obvious mapping from the module name to the XX value, this will make life somewhat harder for people doing translations.
- Who assigns the XX value? How do you avoid clashes if people are independently creating new modules?
- The longest language name is 10 characters long (indonesian) so you theoretically have 5 characters to play with for XX before hitting the 32 character path limit. Perhaps an abbreviation of the module name would work, and solve some of the above questions.

Phil.


CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)

Re: Modular localization
« Reply #3 on: 21 / June / 2017, 10:00:41 »
Thank you for those.

I'm reshuffling them a little, but I'm addressing each.

If you think you can make it work then go for it, based on my knowledge of the module system I think you will face some challenges - especially steps 7, 8 & 9.

We'll see about 7 and 8.

As for 9, I'm removing it for now. AFAIK all strings are currently being kept in memory, so keeping just those that had been loaded wouldn't make it any worse.

Quote
I don't understand why UID's 1 - 4 are reserved for module type.

Those are being (ab)used in menu item hiding.

Quote
Limiting the system to 64 modules MAXIMUM over the lifetime of CHDK seems likely to come back to haunt future developers. Why not 99?. Or use hex values for XX and allow 255?
Quote
Who assigns the XX value? How do you avoid clashes if people are independently creating new modules?

I am operating on the assumption that string IDs remain uint16_t. Since language files (at least now) use decimals, starting at e.g. 5121 wouldn't be very intuitive. Using 0x, on the other hand, would complicate things on both ends.

Re assigning IDs to existing modules: I could do that.

Re future ones: how many are being developed currently?

Quote
There is no obvious mapping from the module name to the XX value, this will make life somewhat harder for people doing translations.
Quote
The longest language name is 10 characters long (indonesian) so you theoretically have 5 characters to play with for XX before hitting the 32 character path limit. Perhaps an abbreviation of the module name would work, and solve some of the above questions.

How about abbreviating the language name instead? That way, we could even welcome en-GB to the neighbourhood ;)
« Last Edit: 21 / June / 2017, 10:25:31 by dmitrys »
Author of CHIMP, Canon Hack Installation and Management Platform


 

Related Topics