RFC: mt_string for Language Strings

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: mt_string for Language Strings

Johan Solve-2
[I suggest we handle suggestions for new data types in this manner, to be able to discuss the specifications in a focused way]

One of the planned but still missing components of Knop is a custom type to handle language string objects.

Here is a proposed specification for the mt_string custom type.

An mt_string object holds all language strings for all supported languages. Strings are stored under a unique text key, but the same key is of course used for the different language versions of the same string.
Strings can be separated into different variables if it helps managing them. This has the downside that the language needs to be set separately for each of the string object instances.

When the language of a string object is set, that language is used for all subsequent requests for strings until another language is set.

        ->addstring:
                required: -key // textkey to store the string under. Replaces any existing key for the same language.
                required: -value // the actual string
                required: -language // one of the standard language codes
        ->getstring // returns a specific text string in the language that has previously been set for the instance.
                                // If the string is not available in the chosen language,
                                // the string for the language that was first specified for that key will be returned.
                required: -key // textkey to return the string for
                optional: -language // to return a string for a specified language (temporary override)
                optional: -replace // single value or array of values that will be used as substitutions
                                                // for placeholders #1#, #2# etc in the returned string, in the order they appear
        ->setlanguage // sets the current language for the string object
                required: -language string
        ->validlanguage // checks if a specified language exists in the string object, returns true or false.
                required: -language string
        ->browserlanguage // autodetects and returns the most preferred language
                                // out of all available languages
                                // as specified by the browser's accept-language q-value
        ->languages // returns an array of all available languages in the string object
                                // (out of the languages in the -language array if specified)
                optional: -language array or string

        ->keys // returns array of all text keys in the string object
       
        ->onUnknownTag // returns the language string for the specified text key = shortcut for getstring.

Examples
        $strings_messages -> loginfailed;
        $strings_errors -> recordlocked;
        $strings_info -> (setlanguage: 'sv');
        $strings_info -> welcome;
        $strings_info -> (setlanguage: ($strings_info -> browserlanguage));


--
     Johan Sölve    [FSA Member, Lasso Partner]
     Web Application/Lasso/FileMaker Developer
     MONTANIA SOFTWARE & SOLUTIONS
http://www.montania.se   mailto:[hidden email]
 (spam-safe email address, replace '-' with 'a')

#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lists.montania.se/Lists/knop/
(log in with your email and ConfirmationID as password, send message to
<[hidden email]> to get that ID)
Project homepage http://montania.se/projects/knop/
AIM chatroom knop aim:gochat?roomname=knop

Reply | Threaded
Open this post in threaded view
|

Re: RFC: mt_string for Language Strings

Jolle Carlestam-2
8 mar 2007 kl. 11.57 skrev Johan Solve:

Handling languages is really something I need to implement into my  
sites so this will really come to use.

But I can foresee a problem with performance. If every text string on  
a page is dynamically inserted then that means a lot of calls to the  
mt_string objects. That means that every millisecond of handling will  
add up and slow down.

So careful consideration in construction is needed.
How are the objects created?
How much code will every call for a specific string process?
Can it be constructed so that all heavy processing is done once, for  
example at startup?

(Got to go, client waiting...)

HDB
Jolle



#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lists.montania.se/Lists/knop/
(log in with your email and ConfirmationID as password, send message to
<[hidden email]> to get that ID)
Project homepage http://montania.se/projects/knop/
AIM chatroom knop aim:gochat?roomname=knop


Reply | Threaded
Open this post in threaded view
|

Re: RFC: mt_string for Language Strings

Johan Solve-2
In reply to this post by Johan Solve-2
At 12.23 +0100 2007-03-08, [hidden email] wrote:
>But I can foresee a problem with performance.

Yes that's right. This ctype is most likely the best candidate for caching.

>How are the objects created?

That's up to the developer. ->addstring could for example be used in a config file if strings are defined in a file, just as the navigation is defined in the example.
->addstring could also be used in a records loop if strings are to be stored in a database.


>How much code will every call for a specific string process?

As little as possible. By storing strings internally as a map (of keys) of maps (of languages), retrieving a string should be very fast since maps are fast.
When setting a language the current language could be prepared and looked up in the main storage so each getstring only needs to look up the key, and not the language. Then it's only one map lookup instead of two for each getstring call.


>Can it be constructed so that all heavy processing is done once, for example at startup?

Yes, caching, caching, caching... Maybe the ctype could optionally use Lasso's cache object to store the strings internally.

--
     Johan Sölve    [FSA Member, Lasso Partner]
     Web Application/Lasso/FileMaker Developer
     MONTANIA SOFTWARE & SOLUTIONS
http://www.montania.se   mailto:[hidden email]
 (spam-safe email address, replace '-' with 'a')

#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lists.montania.se/Lists/knop/
(log in with your email and ConfirmationID as password, send message to
<[hidden email]> to get that ID)
Project homepage http://montania.se/projects/knop/
AIM chatroom knop aim:gochat?roomname=knop