> * Localisation: All the localisation should work seamlessy therefore I
> suggest something like
>
> class ....EnglishLocale {
> var find:String = "Find";
> var matchCase:String = "Match case";
> var highlightAll:String = "Highlight all";
> }
To have a file by language ? (sorry I don't know "seamlessy")
Something like :
function Locale()
{
_default = "en";
_locale = {}
_locale["en"] = org.osflash.usability.text.flashfinder.lang.en;
_locale["fr"] = org.osflash.usability.text.flashfinder.lang.fr ;
}
public function getLocale(s:String):Object{
return _locale[s] ? _locale[s] : _locale[_default];
}
trace(getLocale().find);
?
I think i have to refine the definition of Locale. I will now call it Environment and this Enviroment should of course
contain a way to get a localized string, the standard keyboard shortcuts, a standard user interface (one for each
browser, or at least each platform, maybe?). A locale contains for me informations that apply to environment (mac/win/lin/...)
language (en/de/es/...) and location (us/uk/de/at/ch/es/....). Maybe you could use the same keyset for most environments
but you need to be able to define it for each locale seperatly:
class LocaleManager {
var en = new Locale(English, EnglishKeySet);
var uk_en_win:Locale = new Locale(BritishEnglish, EnglishWindowsKeySet);
var us_en_win_firefox:Locale = new Locale(AmericanEnglish, EnglishWindowsFirefoxKeySet);
// and tons more ...
}
There could/should/must be some fallback to not have for each and every combination a own variable (because that would be insane:
3 platforms * 2 browser * 30 countries = 180 locales ...). I am not yet aware how this should look like.
Anyway, easy stuff first: "getLocale().find" is not good because it doesn't allow to pass any parameters (that might get necessary, or lets say that will be necessary).
LocaleManager.localize("find");
should internally refer to
LocaleManager.getLocale().getLocalisedString("find")
I think too to xml to add new language without recompilate.
(use the the both method, and xml optional)
hmm ... there could be some kind of online service that contains the certain data (if its not available it takes a standard layout out of maybe max. 5).
> * The current way to initialize the application is too complex imho. I
> think its important for
> "miniFlashers" to have ONE function that just includes everything
> (where he doesn't need to
> bother about anything) like:
>
> FlashFinder.use();
With FlashFinder.initialize(target:MovieClip, name:String, depth:Number,
x:.....) only target is necessary and it make all textFields searchable
(ok to use _root if no target).
Uhm ... isn't target, name and depth unnecessary? I mean its certainly
additive and should not be required. And fruter
FlashFinder.include() was only to create the map in cache before
selection....
I think change it and do :
mode "all" (default) >> all Textfields are searchable
mode "include" >> only included TextField are searchable
mode "exclude" >> only non excluded TextField are searchable are searchable
Would be nice for reduced display of options - agree
And I will create FlashFinder.cacheMap(t:TextField) to cache a textField
Map...
What is a textField Map? (sorry for not understanding it)
by the way: I am happy that your working on this!
yours
Martin.
--
ICQ: 117662935
Skype: mastakaneda
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
