1. IntroductionRegarded as the fourth pillar for sustainable development [1] , according to the UNESCO1 Convention on the Protection and Promotion of the Diversity of Cultural Expressions, cultural diversity is a “world heritage” [2] and constitutes a great wealth for the people. Therefore, the protection, promotion and maintenance of cultural diversity are essentials for sustainable development for the benefit of present and future generations. Moreover, as far as computer science is concerns, one can easily agree that, a given user (a human), will use much more intuitively a software if he finds in the latter, elements that are culturally close to him as language, iconography, and the color palette used, etc.
From the observations above, it is clear that it is imperative to take into account the various aspects related to cultural diversity during the development of a software. This is not only to ensure that it is built in respect of the culture of its various end users, but also to produce increasingly easy-to-use software for end users. In order to achieve these objectives, cultural computing2 is the paradigm that should be used if we want to efficiently take into account the possible cultural diversity of end users, when producing a software tool. With this in mind, software publishers, are now using knowledge from cultural computing to improve the user’s experience of each of the end users of their tools: The tool must be constructed in such a way that it is the GUI (Graphical User Interface) that adapts to the user and not the other way around.
In order to produce several (localized) versions of the same software product, publishers use two techniques: internationalization (i18n) and localization (l10n) [4] [5] . Internationalization is the process of generalization which, in software design, allows abstracting it from the peculiarities of a given culture by representing intentionally the objects which it manipulates. According to Schäler [6] , localisation is “the linguistic and cultural adaptation of digital content to the requirements and locale of a foreign market, and the provision of services and technologies for the management of multilingualism across the digital global information flow”.
In order to perform a linguistic and cultural adaptation of an application, among other activities, its GUIs must be translated to the signifiers, the habits, etc of targets cultures. Figure 1 presents two located examples of George Weah’s bibliography in Wikipedia for Francophone culture3 (Figure 1(a)) and for Arab culture4 (Figure 1(b)). On these figures, we can notice some differences concerning the language used, the position of images and menus, colors, etc.
Most single-user software used around the world are not located. It’s even worse when you consider the case of those running on a network5, because for such applications, it might be ideal to offer to each application user at a given time, a GUI who is consistent with its own culture. For example, it’s about designing a multiplayer game or a collaborative editing application so that, each participant interacts on a located GUI in their culture. This is what we call
multi-localization or simultaneous localization and this is what constitutes the main objective of this paper: to propose a new approach of external multi-localization of GUIs of collaborative and interactive software.
Starting from the observation that the tree structure of a GUI can be represented intentionally by an abstract syntax tree (AST) for a given context-free grammar (see Section 2.1), we borrow techniques and tools from the domains of language theory, compilation, and functional programming, to show that, a particular localization of a GUI represented intentionally by an AST, is in fact only a particular interpretation of this AST according to a given algebra: this is the formal base on which our multi-localization approach is based.
More precisely, from an abstract grammar (AST’s model of GUIs of a given application), we deduce: 1) Haskell data types6 [7] [8] for each of its grammatical symbols, 2) types for algebras that will be use to write as many interpreters as wanted, in as many GUI description languages (FXML7 [9] , UIML [10] , etc.), 3) evaluation functions, each parameterized by both an algebra and a localization file which will make it possible to locate the AST by interpretation. A synoptic view of the proposed approach is sketched in Figure 2.
Organization of the manuscript: Section 2 introduces some concepts related to software localization and GUI modeling using context-free grammars (CFG). Our multi-localization approach, followed by its experimentation (derivation of multi-located GUIs for a network checkers game) is presented in Section 3, while Section 4 is devoted to the conclusion.
2. Preliminaries2.1. Context-Free Grammars as GUI’s ModelsA graphical window (GUI) consists of a set of basic components8 (Image, Menu, Table, Text Box, etc.), arranged in relation to each other (horizontally, vertically,
etc.) to a precise positions on the window by means of the so called structural components9 [11] [12] . Presented this way, one can easily realize that, the rules governing the grouping of the (basics and/or structural) components of a GUI can be described using the production rules of a CFG. Therefore, a GUI (tree structure) can be intentionally represented by an AST of a CFG. In fact, for a given graphical application, we can construct a CFG in such a way that, any of its GUIs is intentionally represented by an AST of the latter (see Section 3.2.1): CFG can be used as models of the GUIs of an application. This is the use made of it in this paper.
Recall that a CFG defines the structure of its instances (AST) by means of productions. A production, generally denoted p : X 0 → X 1 ⋯ X n is assimilated in the GUIs context, to a structuring rule showing how the component X 0 , located on the left hand side of the production, allows structuring/grouping the other components X 1 ⋯ X n located on the right hand side. More formally, we have the following definition:
Definition 1 An abstract context free grammar (CFG) is given by G = ( S , P , A ) composed of a finite set S of grammatical symbols or sorts corresponding to the different syntactic categories involved, a particular grammatical symbol A ∈ S called axiom, and a finite set P ⊆ S × S ∗ of productions. A production P = ( X P ( 0 ) , X P ( 1 ) ⋯ X P ( | P | ) ) is denoted P : X P ( 0 ) → X P ( 1 ) ⋯ X P ( | P | ) , | P | denotes the length of its right hand side and l h s ( P ) (resp. r h s ( P ) return its left (resp. right) hand side. A production with the symbol X as left part ie. #Math_20#, is called a X-production.
An AST is a tree whose nodes are labeled by the grammatical symbols of the grammar and is such that, for any internal node labeled X , having n sons labeled X 1 , ⋯ , X n , rule X → X 1 ⋯ X n must be a grammar production. Moreover, the leaf nodes must be associated with ε -productions.
Definition 2 The set A S T ( G , X ) of abstract syntax trees according to the grammar G associated with grammatical symbol X consists of trees in the form X [ t 1 , ⋯ , t n ] where X is the label of the root node10 of the tree, t 1 ⋯ t n are subtrees of the root node and there is a production P : X → X 1 ⋯ X n such that X = X P ( 0 ) , n = | P | and t i ∈ A S T ( G , X i ) for all 1 ≤ i ≤ n .
AST can be interpreted as evidence of the conformity of the GUI (tree structure) with the grammar.
2.2. On Software Localization: External vs. Inner LocalizationThe localization of a software does not only concern its GUIs. This is an activity that also includes the technical documentation provided with the software (installation guides, user manuals, etc.), online help and so on [13] .
When the need to locate softwares was felt, the first answer given to this new challenge by the software publishers was purely linguistic and recommended working directly on the source code of the application: this is what we call inner software localization [4] . Since the strings to be translated are generally scattered throughout the application’s code, the localizer must have access to it. The latter must then be either a translator with programming knowledge, or a programmer with translation knowledge, or both must work in perfect intelligence.
Granting free access to the source code to a third party who is not the editor poses at least the problem of security and confidentiality. Indeed, since translators do not generally have a great programming knowledge, the risk is great that they inadvertently modify, or copy for unconfessed purposes the source code available to them for translation [4] .
In the early nineties, a new form of localization using resource files11 and called external software localization [14] has been created. It allows translators to process the text contained in the GUIs without need to have any particular programming knowledge, or to constantly need the assistance of the programmers. They only intervene on the resource file (containing localizations of localizable elements such as text, etc.) which is subsequently delivered with the software product. In production, the choice of the localization to use for a particular running of the software is done either interactively at the start of the software, or is previously set in a configuration file. By doing so, the software developed is not only completely independent of the end user culture, but is also highly extensible from a localization perspective. Indeed, it is enough to create a new localization file containing data relating to a new culture, for it to be taken into account by the tool.
Recall that the work presented in this manuscript focuses exclusively on the external localization of GUIs.
3. A grammatical Approach of External Multi-Localization of GUIs3.1. Derivation of a (Parameterized) Functional Interpreter of ASTsWe have seen (section 2.1) that the logical structure of a GUI can be represented by an abstract CFG.
Let G 1 = ( S , P , A ) with P = { P 1 : X → X 1 ⋯ X n , P 2 : X → Y 1 ⋯ Y m , ⋯ , P k : X → Z 1 ⋯ Z l } , be a grammatical model of GUIs of a software. We present in this subsection how to encode G 1 , its ASTs as well as their interpreters in the functional language Haskell.
Well-known techniques describing how to carry out a functional implementation of a CFG, and how to write interpreters of its ASTs exist [15] [16] . We briefly present below how we proceed. Note that, our way of doing things is not fundamentally different from others but has the advantage of being modular. Indeed, whereas generally a single algebra structure is associated with a grammar, we suitably associate an algebra structure with each syntactic category of the grammar and consider in fine that, the algebra structure associated with the grammar is the one associated with its axiom.
Abstract grammar allows to specify syntactic structures that can be associated in Haskell to a set of algebraic data types12 describing the different syntactic categories used in grammar. Terms of a data structure are generally subject to several interpretations, all of them following the same recursion pattern. This is why they are generally specified by means of algebras13 formally defined as follows:
Definition 3 Let G = ( S , P , A ) be a CFG. An algebra A X associated with a grammar symbol X ∈ S is given by: 1) an interpretation domain D Y associated with each grammar symbol Y appearing in a X -production of P , 2) a reference to the A Z algebra of each grammar symbol Z appearing on the right-hand side of a X -production. 3) an application P A : D X P ( 1 ) × ⋯ × D X P ( | P | ) → D X associated with each X -production P : X → X P ( 1 ) ⋯ X P P ( | P | ) . The algebra A G associated with the grammar G = ( S , P , A ) is the one associated with his axiom A : A G = A A .
Given an abstract grammar G = ( S , P , A ) , we deduce from systematic way the Haskell data types, the associated algebra data types, and the evaluation functions (catamorphisms14) as follows:
1) A data type is created for each grammar symbol.
2) For each created data type, an associated algebra data type is created. It consists of two groups of selectors:
• The group formed by types of interpretation functions of algebraic data type: there is one for each data constructor of algebraic data type,
• The group containing references to algebras associated with the different algebraic data types used in the definition of the type of which the current algebra is associated.
3) For each data type created, an evaluation function encapsulating the recursion pattern is created; it is parameterized by the algebra associated with this data type.
Application of the approach to the grammar G 1
1) Creating data types:
![]()
2) Creation of data types for algebras: D X i denotes the type variable representing the interpretation domain of the type X i .
![]()
3) Evaluation function parameterized by algebra data type associated to X data type15.
![]()
3.2. A Multi-Localization Approach: The StepsIn order to be intensively localizable, GUIs have to be internationalised to abstract any information directly related to a culture. This justifies the decomposition of our multi-localization approach into two phases: an internationalization phase whose objective is to produce a grammatical model (an abstract grammar) of all the GUIs of the software; followed by a phase of multi-localization, whose objective is to produce on the fly, located GUIs for each of the participants in the collaboration.
3.2.1. The Internationalization PhaseThe internationalization phase can be considered as an analysis-design phase, allowing not only to identify the localizable elements of the GUIs for the abstraction purpose, but also to highlight the structural relations which exist between them. Only a summary description of this phase is given below, because it is not the main object of this study. It takes place in four steps:
1) Sketching: produce a sketch of all the GUIs of the software. This can be done because, this set is finished.
2) Identification: identify for each GUI the localizable elements for their abstraction; symbolic names will be found and only one occurrence of similar elements appearing in more than one GUI is retained.
3) Production of ASTs: identify the structural relationships between localizable elements of the GUIs and for each relation identified, study constraints related to the relationship; for example, the meaning of the relation that can be different from one culture to another, etc. This step ends with the production of an AST draft for each GUI: this is its intentional representation.
4) Derivation of the grammar model of the application’s GUIs: from the different ASTs produced in the previous step, derive their CFG by considering that, the set of AST’s labels form the set of grammatical symbols and that, a label of a inner node and those of its directs children form a production.
3.2.2. The Multi-Localization PhaseThis phase starts after the previous one and takes as input the grammar produced. It takes place in three steps (see Figure 2):
1) Generation of data structures: generate from the grammar data structures, algebras data structures and evaluation functions for each grammatical symbol (Figure 2-Step1) as described in section (see section 3.1).
2) The choice of GUIs description language(s) and cultures to be located: the produced GUIs are described in a (textual) language like FXML [9] , UIML [10] , etc. An implementation of algebra must therefore be provided for each of the target GUI (textual) description languages. Likewise, a localization file must be produced for each target culture (Figure 2-Step2).
3) Multi-localization: at the running time, the located GUI is obtained by invoking the evaluation function associated with the axiom of the grammar. An instance of algebra corresponding to the desired description language, and the localization file related to the target culture are provided as effective parameters during this invocation (Figure 2-Step3).
External localization of software uses resource files that can be in the binary (.DLL, .EXE, etc.) or text format. In the following, we will call localization file a text resource file, containing in addition to strings to display in the GUI (linguistic aspect), other cultural information (color codes, disposition order of components, etc.) whose suitable use by the ASTs interpretation functions will provide a located GUI in which, not only linguistic concerns are addressed.
A localization file is structured in sections, and each of them contain information about a specific cultural concern addressed (language, color, components layout, etc.). Each section is structured as an associative list, ie. a list of pairs (key, value) where key is the identifier of a resource (its internationalized form), and value its concrete representation in the current target culture. We have on the listing 6 an example of a localization file.
3.3. Experimentation: Application to the Multi-Localization of the Checkers Game GUIRecall that checkers game consists of a set of pieces that moves according to precise rules, on a checkerboard made up of 100 squares. It is played by at least 2 players and each player has 20 pieces of single color, which is distinct from the color of pieces of the other player. The goal of checkers game is to take or block the largest number of opposing pieces.
Considering that a checkers game can only be played by at least 2 players, it can be implemented and played in a network: it is therefore a kind of cooperative application. One can easily imagine a checkers game played by participants belonging to different cultural areas. As mentioned in the introduction (Section 1), the game’s GUI can be multi-located in order to improve for each player his application’s use comfort: each of the participants will then interact on a located GUI relating to his culture.
The rest of this subsection presents how this goal can be achieved by applying the multi-localization approach described in Section 3.2. Note that our goal here is not to build a fully functional checkers game, but, to present how our approach can easily derive a multi-located GUI for the latter. For a better understanding of the example, we presented on Figure 3, the orchestration diagram summarizing the interaction between different players during a game: any action of a player (moving a piece) on his GUI is raised at the AST level and the GUI of the other player is immediately updated accordingly; bidirectional binding [17] is implemented between each localized GUI and the AST.
3.3.1. Localizable Elements and AST of the Checkers GameFor illustration purposes, we have retained in addition to the GUI components related to the linguistic aspect, some others whose interpretation may vary from one culture to another. Finally, the localizable elements selected for our toy application are: strings (the linguistic aspect), colors, images of the pieces, layout
components of the GUI and the chronometer displaying the remaining time at the end of which the player must have moved a piece: his color will have to change as soon as this time reaches a certain threshold.
From the abstraction of its elements and the structural relations that can be identified between them, we have the AST of Figure 4 in which, the components Label, Button, ImageView, TextField (resp. Vbox, Hbox, Gridpane) are abstractions of basic (resp. structuring/layout) components that names are related to those that we generally have in the GUI’s build libraries.
3.3.2. GUI’s Grammar for the Checkers GameFrom the abstract representation of checkers game (Figure 4) one can derive abstract grammar whose productions (an extract) are presented on the listing 1.
Listing 1: GUI’s grammar for the checkers game
In the listing 1, grammar symbols that do not appear on the left hand side of any production are assumed to be associated with ε -productions (not shown in this listing). In addition, in line 3, the notation “*” simply means that the grammar symbol Vbox is used to structure zero or more BaseCompOrGroup components.
3.3.3. Data Structures Derived from the Grammar of the Listing 1An extract is given in the listing 2. Note that, a flat must be made to what have been said in Section 3.1 with regard to the data types to create. In fact, we will not create neither a Haskell data type nor algebra for grammatical symbols that we call linguistic symbols; these are symbolic names whose concrete value in the language of target culture is given in the localization file. In the listing 1, these are the grammatical symbols whose names have “.game” as extension; they are represented by the type String (their domain of interpretation) in the listing 2, lines 7 and 8.
Listing 2: Data structures derived from the grammar of the listing 1
![]()
Listing 3 presents the Haskell code of the algebraic structures associated with the data types of the listing 2. In this one, the types variables D V b o x , D H b o x , D A s t , etc. represent the interpretation domains of the respective components, Vbox, Hbox, Ast, etc. Note that, the interpretation functions of derived algebraic structures, use data contained in the localization file. The latter is therefore provided as a parameter (listing 3, lines 7 and 10), and treated as an inherited attribute16 associated with all the syntactic categories of the grammar.
During the scanning of a linearization of the AST, the checkers board is generated when GridPane is met. The syntactic categories BaseCompOrgroup, BaseComp and Ast are used only for factorisation purposes (reducing the number of productions), the interpretation functions of algebra that are associated do not use data contained in the localization file: they do not take it as a parameter as it is the case for other algebras.
Listing 3: Some algebras structures derived from the grammar of the listing 1
![]()
As for the interpretation functions of algebras, the evaluation functions parameterized by algebras (listing 4) use data contained in the localization file; it is therefore provided as a parameter to these functions, and they must propagate it in the AST, by making them available at the level of each of their sons (listing 4, line 4).
Listing 4: The catamorphisms associated with the algebras of the listing 3
![]()
3.3.4. An Implementation of Algebra for FXMLFor the checkers game, we chose FXML as the GUI description language. All syntactic categories, except those qualified as linguistic symbols, therefore have FXML as interpretation domain. A particular implementation of the algebra of the listing 3, of which an extract is given in the listing 5, makes it possible to encode the located GUIs in FXML. It basically contains instructions for creating (insertion of tags) a well-formed and valid FXML file.
Listing 5: An algebra for the localized interpretation of AST in FXML
![]()
3.3.5. Localization FilesFor illustrative purposes and without detracting from the generality, we have choose to multi-locate the GUI of the checkers game according to two cultures: “Western like culture” and “African like culture”. Their respective localization files are given in the listings 6 and 7. They have been save in files named respectively fichLocalWestern and fichLocalAfrican, which are used in listing 8.
Listing 6: Localization file for a “Western like culture”
![]()
Listing 7: Localization file for an “African like culture”
![]()
3.3.6. Located GUIsThe FXML codes of the located GUIs of the AST of the Figure 4, in each of the two target cultures, are obtained by invoking the function cataAST (listing 8) as described in the subsection 3.2.2. Once the FXML files are created, they can be viewed by using a FXML interpreter such as sceneBuilder17 to have the outputs given by Figure 5.
Listing 8: FXML localizations of the AST of the Figure 4
![]()
4. ConclusionsIn this paper, we presented an external multi-localization approach of GUIs of interactive software. It can be used for the implementation of both collaborative and standalone applications, in order to adapt on the fly the end user’s GUI to its own culture: The user experience is therefore improved.
The approach has been experimented with great satisfaction for the development of the multi-located GUI of checkers game, whose main lines of its implementation have been presented in this manuscript.
The proposed approach is based on the use of functional techniques for the interpretation of abstract structures by the means of algebras. The use of algebras gives to the programmer the latitude to offer with a lower intellectual investment the same localizations in various GUI description languages. Since the kind of localization explored in this paper uses localization files, the proposed
approach may allow even a non-computer specialist to increment the localization degree (adding a new culture) of a software as soon as it has already been located for at least one culture: It is enough for that to adequately create a new localization file for the new target culture. Note however that, the creation of the new file will be easier if one can do it by the mean of a DSL (Domain Specific Language) [18] ; this is one of the immediate perspectives of this work: that is, to investigate about an implementation of the proposed method as a software system, that generate code from high-level description, in order to not leave too much manual low-level writing of boilerplate code (like the one in the listing 5) to the software developer.