We were discussing SDK and command line interface CLI options in addition to the APIs which improve the customer base.
Let us now talk about locale. Every user belongs to a geography and hence has a preferred language for the login page. When the user is displayed a web page, most of the strings on the web page are translated to a language of his or her choice. These translations can be made available with the user interface as language packs so that the corresponding translations may show up on the page. Care must be taken that all translations exist in every locale supported by the user interface. Also, when a language specified is invalid or a translation could not be found by an identifier, the corresponding default strings from english language can be displayed.
Let us now talk about locale. Every user belongs to a geography and hence has a preferred language for the login page. When the user is displayed a web page, most of the strings on the web page are translated to a language of his or her choice. These translations can be made available with the user interface as language packs so that the corresponding translations may show up on the page. Care must be taken that all translations exist in every locale supported by the user interface. Also, when a language specified is invalid or a translation could not be found by an identifier, the corresponding default strings from english language can be displayed.
If a web page is viewed as an html, text usually appears as span within a div. These div only indicate the position but their content is decided by the rendering engine such as Razr. The literals in the html are looked up based on a identifier that acts as its alias. The same alias may be used for the translations of the string in different languages. Since the (alias, locale) pair is unique, we know that there will be a unique translation for the string. When the view is prepared, these literals are pulled from the database. Usually this preparation happens on the server side. If it were assets such as css, javascript or static html, then they could be served by the content delivery network which ensures that they are as geographically close as possible to the user. String are resources too but they don't appear as a resource on the CDN because there is a computation involved. But technically each string may be placed in its own static file and the sections of the html that display the content may instead serve the literal via loading a file. Round trips from a CDN are generally not considered expensive but given that there may be many literals on a page, this could become expensive. Each CDN may also need to keep its own copy of the literals. This means we don't have the single point maintenance on the server side as we did earlier. Moreover, updates and deletes of the string involves making changes to all CDN. But it is not impossible to offload the literals as a resource so that html can load it on the client side without having the server to incur the work.
No comments:
Post a Comment