Writing a Multilingual Opera Unite Application (Part 1)

    Unfortunately, Opera does not yet support the localization of widgets using the method proposed in the W3C standard , but even if it does, it only affects the server side, and, apparently, only the server language. Therefore, we will do everything ourselves, given that the languages ​​of the browser server and the client browser are generally different.

    Receiving from the server side the language of information sent to the client

    How to determine the client language on the server? - The HTTP Accept-Language header . How to get to it? - through the getRequestHeader method or the headers property of an object of type WebServerRequest . And then process it using the algorithm described in the RFC? - Yes. To do this, I wrote a function that accepts WebServerRequest and a list of supported localizations, and produces the client-preferred localization:
    function getLanguageNameForRequest (Request, SelectedArray) {
    	var HeaderCollection = Request.getRequestHeader ("Accept-Language");
    	var AcceptString = "";
    	if (HeaderCollection! = null) if (HeaderCollection.length> = 1) {
    		// HeaderCollection is a DOMStringList and does not have a join method, so pornography
    		for (var i = 0, AcceptString = HeaderCollection.item (0); i= 0) {
    			if (q> Qu) {
    				Lang = l;
    				Qu = q;
    			}
    		}
    	}
    	return Lang;
    }
    
    Call example
    For example, if a client sent the line “ru, ru-RU; q = 0.9, en; q = 0.8, de; q = 0.7” in the Accept-Language header, and the languages ​​“ru” and “en” are supported on the server, then getLanguageNameForRequest will return "ru":
    window.onload = function () {opera.io.webserver.addEventListener ('_ index', function (RequestEvent) {
    	RequestEvent.connection.response.writeLine ("Client language:" + getLanguageNameForRequest (RequestEvent.connection.request, ["ru", "en"]));
    	RequestEvent.connection.response.close ();
    }, false);}
    Why not use UserAgent instead? Because it conveys the language of the browser interface, not the pages.

    Receiving from the server side the language of information output to the server

    A feature of Opera Unite technology is that the server script interacts not only with people who receive HTML through client browsers, but also with the person sitting at the server browser directly through various APIs, for example, sending messages via widget.showNotification . Fortunately, the same DOM is available for server code as for a regular page, that is, window.navigator.language works and displays the language of the browser-server interface. In a function similar to the previous case, we wrap a function that selects a language from the available ones:
    function getLanguageNameForServer (SelectedArray) {
    	var l = window.navigator.language
    	return (SelectedArray.indexOf (l)> = 0)? l: SelectedArray [0];
    }
    widget.showNotification ("Server language:" + getLanguageNameForServer (["en", "ru", "de"]));

    Creation of infrastructure for localization of the application as a whole

    Since one of the most important advantages of Opera Unite is the ability to use the same JavaScript code both in the server and client parts of the application, I would like not to lose this property when creating the API for localization, that is, the language of the returned lines must be implicitly determined by the place executing code that asks them. This will be the second part of the post, if I write it.

    Also popular now: