|Pliant talk forum
Feature request: Locale support to extend beyound language
Locale should be more general and should allow several
settings, with cascade/fallbacks.
|Message posted by maybe Boris Reitman on 2008/08/03 23:29:22
|For example I can set language to
[ english-canadian, english-american, english-british ]
and it will try to find canadian english translation,
if that faills it will take american, and if all faill it will take british.
also, locale is more than a langauge, it could be any kind of configuration,
I will be able to define conjugation of area name, which I need for
"in $AREA$" "на Брайтоне"
"of $AREA$" "Брайтона"
so that when I subsitute it into text it will be a readable russian.
So by creating a file for my area, which will only have these three strings,
and another file for all russian translations, and then I can set
locale to: [ russian-brighton-beach, russian ]
it will try to lookup something in russion-brighon-beach and if it is
not there it will pick it from main russian locale.
|Message posted by maybe Hubert Tonneau on 2008/08/05 01:06:49
|I'm not sure to have understood all the subtilities you expect.
If we just expect to have a list of language preferences, then there are two
1) store the list in the thread header, and do multiple lookups when casting
to a standard string.
2) include an inheritance notion in external translation files so that each
language would be complete in the end.
The problem with 1 is the impact on execution speed.
The problem with 2 is that the same string will be stored several times.
A possible solution would be to have a more flexible lStr encoding that would
enable everal language indices to use the same characters.
I have no conclusion at the moment.
|Message posted by maybe Boris Reitman on 2008/08/05 14:12:00
|Number 1 because loss in speed only happens when more than one language listed.
Adobe Flex does it this way.