I think we should organize thoughts with these use cases in mind. Please correct me as you see fit - but this is how I see things breaking down (descending order based on number of people in each group).
1) people who want a single language (theirs) 2) people who want dynamic translation I almost put 0) people who don't know about language since that is the case that OpenLayers currently considers - but I didn't want to make anybody angry. Anyway, I'd like to see things done so we don't sacrifice efficiency for people who want a single file build that just includes their single language. Having every element that contains a string registered as an event listener starts sounding a bit heavy for this case. And, in terms of parsing strings for formatting, isn't it enough to break elements up based on the portions that can be translated: <p>OpenLayers <span i18n="rocks">rocks</span></p> ? This doesn't work for alert(str), but I happen to think we should purge alerts from the library. Being contrary, Tim PS- Also, I know the i18n attribute is too simple to deal with element attribute values that need translating themselves (<img src="..." alt="translate me">). In that case, we need multiple attributes in the i18n namespace (something akin to http://wiki.zope.org/zope3/ZPTInternationalizationSupport). Erik Uzureau wrote: > On 10/18/07, Christopher Schmidt <[EMAIL PROTECTED]> wrote: >> On Thu, Oct 18, 2007 at 03:46:21PM -0400, Paul Spencer wrote: >>> On 18-Oct-07, at 2:31 PM, Christopher Schmidt wrote: >>> >>>> setLanguage, if we're going to provide a method for it, is going to >>>> need >>>> to be more complex than that. We'd have to loop through the controls, >>>> and call redraw() on them, to update their text, and I'm not sure that >>>> all controls would support a redraw correctly. >>>> >>> Could we use an event that is triggered and then controls that have >>> strings can register (or be registered) for the language changing? >>> >>> OpenLayers.String.events.register('languagechange', >>> OpenLayers.Function.bind(this, this.onLanguageChange)); >> I like this idea. I hadn't thought of it, and it makes sense. > > yes, i like it to. the only thing i dont like about it is that it > seems like it might sort of be a burden to control developers to have > to deal with registering events. > > to that end, we might consider such a thing as making the base > OpenLayers.Control's constructor register the listener and call a stub > function udpateLanguage() or something like that. In > OpenLayers.Control, the stub function would do nothing. Then if > controls _do_ wish to update on language changes, they need only > implement the updateLanguage(). > > This might help in the case of a control that is subclassed from > another control -- the updateLanguage() calls would be chained up, > instead of having to register a separate listener for each class. > > I dunno. This is just the first thing that comes to mind... that as a > control developer it seems like kind of a PITA and or unnecessary > overhead to be registering more listeners. > > --E > > >>> We will probably want a LanguageSwitcher control that sets the >>> language and tracks the current language too, mostly for testing and >>> development. >> I'm not convinced that we need that, but if it gets built as part of >> development, it would probably be useful. >> >>> We need a way of indicating what languages to support in any given >>> application, and of enumerating the supported languages through the >>> OpenLayers API. >> for (var key in OpenLayers.Strings.languages) { >> alert(key); >> } >> >>> We need a way to extend the base set of translations with other, >>> application-specific translations. >> OpenLayers.Strings.languages['eng']['My Application String!'] = 'My >> application String!'; >> >> OpenLayers.Strings.languages['spa']['My Application String!'] = >> '¡String Applicacion de mio!'; >> >> Regards, >> -- >> Christopher Schmidt >> MetaCarta >> > _______________________________________________ > Dev mailing list > [email protected] > http://openlayers.org/mailman/listinfo/dev > > !DSPAM:4033,4717d058293873327367457! > _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
