Polyglot Frontier: Proposal: #language framework

{ filsa.net: Polyglot Frontier - Introduction | Resource Index | Get Involved }

Polyglot Frontier: promoting multi-lingual support for Frontier

Originally published on 8/5/97; 7:32:23 PM

Proposal: #language framework

Nobumi Iyanaga's implementation of a language framework for Frontier web-site building.

NOTE: This language framework is in flux for Frontier 5. Stay tuned.
What is the #language framework?
The #language framework is a very simple modification to the html suite that allows modular extenson to Frontier's rendering process. With a single directive, #language, it is possible to divert the rendering process at key points to do special processing on the text (which will vary depending on the language).
This is especially important for double-byte languages, which Frontier currently doesn't have support for. With the #language framework, it's easy for third parties to plug into the rendering process without making changes that will get erased in the next update of Frontier.
Where is the language framework stored in the object database?
It's kept in a subtable of user.html.macros.language. For example, the scripts that make up the functionality of the Japanese part of the framework are stored in user.html.macros.language.Japanese.
Thus, it's very easy for the hooks into the html suite to work. Before certain crucial points in rendering, the html suite checks the language preference. If it returns something other than true, the language is defined. In a try statement we attempt to run the appropriate script for that language. Sample code looks like this:

if html.getpref (language) != true try {user.html.macros.language.[html.data.page.language].pagefilter()}
Where does the language framework need to make hooks?
Well, it depends on the language, but in general, for double byte languages, the current HTML suite needs patches in the following scripts:
html.buildObject html.data.standardmacros.glossaryPatcher html.processMacros html.data.standardmacros.renderObject
Basically, before the pagefilter and finalfilters, before macro processing and glossary patching, and when rendering certain odb object types (outlines) some pre-processing is needed.
Why is this important?
Well, it's not important for everyone.
But for those who work across languages, or who work in more than one language, it's good to know about a structure that has already been developed to handle languages. It will save work, and make maintenance of the root easier, as well as simplify updating of the html suite.
It's a wide open framework. Inside each language's subtable of user.html.macros.language, the scripts can be set up as needed. The hooks are set up in try statements, so if a script isn't where it should be, it's not a problem.
Will the html suite ever ship with these hooks built in?
Well, that's up to Userland software. I think that it's something worth considering, something that ought to go up for discussion. I feel that at the moment most Frontier developers work mostly in English. But I think that will change, as more people find out about Frontier here in Japan and around Asia.
Planning for international systems and different language systems is a good idea for both the html suite and for the Frontier application, especially as Frontier heads cross platform. If you think more international language support is a good idea, say so. Get Involved in this site, express your opinions (respectfully) on the various Frontier lists, and promote use of Frontier in your native tongue.
The goal of this site is to promote better International langauge handling in both scripts and the Frontier distribution, with cooperation from Frontier users and Userland software.
Where is the framework?
It's distributed by the author, Nobumi Iyanaga. It's available from his his Frontier page (Japanese web authoring kit for Frontier). Please take a look if you are interested.

Site Outline
Previous | Next

Other filsa.net services: Frontier Scripting | Script Archive

This is part of Phil's Frontier Scripting Site.
Osaka, JAPAN
Copyright © 1996-97, Phil Suh. All Rights Reserved.
http://www.filsa.net/frontier/polyglot/framework.html
This page last built on 6/28/99; 11:09:00 PM


Originally published on 8/5/97; 7:32:23 PM Proposal: #language framework Nobumi Iyanaga's implementation of a language framework for Frontier web-site building.
	NOTE: This language framework is in flux for Frontier 5. Stay tuned. What is the #language framework? The #language framework is a very simple modification to the html suite that allows modular extenson to Frontier's rendering process. With a single directive, #language, it is possible to divert the rendering process at key points to do special processing on the text (which will vary depending on the language). This is especially important for double-byte languages, which Frontier currently doesn't have support for. With the #language framework, it's easy for third parties to plug into the rendering process without making changes that will get erased in the next update of Frontier. Where is the language framework stored in the object database? It's kept in a subtable of user.html.macros.language. For example, the scripts that make up the functionality of the Japanese part of the framework are stored in user.html.macros.language.Japanese. Thus, it's very easy for the hooks into the html suite to work. Before certain crucial points in rendering, the html suite checks the language preference. If it returns something other than true, the language is defined. In a try statement we attempt to run the appropriate script for that language. Sample code looks like this: if html.getpref (language) != true try {user.html.macros.language.[html.data.page.language].pagefilter()} Where does the language framework need to make hooks? Well, it depends on the language, but in general, for double byte languages, the current HTML suite needs patches in the following scripts: html.buildObject html.data.standardmacros.glossaryPatcher html.processMacros html.data.standardmacros.renderObject Basically, before the pagefilter and finalfilters, before macro processing and glossary patching, and when rendering certain odb object types (outlines) some pre-processing is needed. Why is this important? Well, it's not important for everyone. But for those who work across languages, or who work in more than one language, it's good to know about a structure that has already been developed to handle languages. It will save work, and make maintenance of the root easier, as well as simplify updating of the html suite. It's a wide open framework. Inside each language's subtable of user.html.macros.language, the scripts can be set up as needed. The hooks are set up in try statements, so if a script isn't where it should be, it's not a problem. Will the html suite ever ship with these hooks built in? Well, that's up to Userland software. I think that it's something worth considering, something that ought to go up for discussion. I feel that at the moment most Frontier developers work mostly in English. But I think that will change, as more people find out about Frontier here in Japan and around Asia. Planning for international systems and different language systems is a good idea for both the html suite and for the Frontier application, especially as Frontier heads cross platform. If you think more international language support is a good idea, say so. Get Involved in this site, express your opinions (respectfully) on the various Frontier lists, and promote use of Frontier in your native tongue. The goal of this site is to promote better International langauge handling in both scripts and the Frontier distribution, with cooperation from Frontier users and Userland software. Where is the framework? It's distributed by the author, Nobumi Iyanaga. It's available from his his Frontier page (Japanese web authoring kit for Frontier). Please take a look if you are interested.
Site Outline Previous \| Next