Reference number of working document: ISO/IEC JTC1/SC22/WG20 N553 Date: 1997-12-21 Reference number of document: ISO/IEC FCD 14652 Committee identification: ISO/IEC JTC1/SC22 Secretariat: ANSI Information technology Specifications for Cultural Conventions Technologies de l'information Spcifications des conventions culturelles Contents 1 SCOPE 1 2 NORMATIVE REFERENCES 1 3 TERMS, DEFINITIONS AND NOTATIONS 1 4 FDCC-set 4 4.1 FDCC-set definition 5 4.2 LC_CTYPE 8 4.3 LC_COLLATE 22 4.4 LC_MONETARY 36 4.5 LC_NUMERIC 41 4.6 LC_TIME 41 4.7 LC_MESSAGES 47 4.8 LC_PAPER 48 4.9 LC_NAME 48 4.10 LC_ADDRESS 51 4.11 LC_TELEPHONE 52 4.12 LC_MEASUREMENT 52 4.13 LC_VERSIONS 54 5 CHARMAP 59 6 REPERTOIREMAP 62 7 CONFORMANCE 88 Annex A (informative) DIFFERENCES FROM POSIX 89 Annex B (informative) RATIONALE 91 Annex C (informative) INDEX 106 BIBLIOGRAPHY 111 FOREWORD ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non- governmental, in liaison with ISO and IEC, also take part in the work. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. International Standard ISO/IEC 14652 was prepared by Joint Technical Committee ISO/IEC JTC 1., "Information Technology", subcommittee 22, "Programming languages, their environments and system software interfaces". The Standard uses text from ISO/IEC 9945-2:1993 "Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities", primarily clauses 2.4 and 2.5. The major differences from this text is listed in annex A. The annexes A, B and C are for information only. Introduction This International Standard defines a general mechanism to specify cultural conventions, and it defines formats for a number of specific cultural conventions in the areas of character classification and conversion, sorting, number formatting, monetary formatting, date formatting, message display, paper formats, addressing of persons, postal address formatting, telephone number handling, measurement handling, and a way to specify how much is covered and the status of it. There are a number of benefits coming from this standard: Rigid specification Using this International Standard, a user can rigidly specify a number of the cultural conventions that apply to the information technology environment of the user. Cultural adaptability An application may use the specifications as data to its APIs, and thus the same application may accommodate different users in a culturally acceptable way to each of the users, without change of the binary application. Internationalization An application developer can remove cultural dependencies from an application, using the localized data given by the customer. In this way the application developer is relieved from getting the different information to support all the cultural environments for the expected customers of the product. The application developer is thus ensured of culturally correct behaviour as specified by the customer, and possibly more markets may be reached as customers can provide the data themselves for markets that were not targeted. Uniform behaviour A user may use his/her cultural convention specifications with a number of applications, and thus enjoy consistent and correct behaviour on these issues from all of the applications. The specification format is very general, independent of platforms and specific encoding, and targeted to be useable from a wide range of programming languages. This International Standard defines the format to be used for the International String Ordering standard, ISO/IEC 14651. This Internal Standard is backwards compatible with the ISO/IEC 9945:1993 POSIX shell and utilities standard, and it has enhanced functionality in a number of areas such as ISO/IEC 10646 support, more classification of characters, transliteration, dual currency support, enhanced date and time formatting, paper handling, personal name writing, postal address formatting, telephone number handling, measurement system handling, and management of categories. There is enhanced support for character sets including ISO 2022 handling and an enhanced method to separate the specification of cultural conventions from an actual encoding via a description of the character repertoire employed. A standard set of values for all the categories has been defined covering the repertoire of ISO/IEC 10646. Information technology Specifications for cultural conventions 1 SCOPE This Standard specifies a description format for the specification of cultural conventions, a description format for character sets, and a description format for binding character names to ISO/IEC 10646, plus a set of default values for some of these items. The specification is upward compatible with POSIX locale specifications - a locale conformant to POSIX specifications will also be conformant to the specifications in this Standard, while the reverse condition will not hold. The descriptions are intended to be coded in text files to be used via Application Programming Interfaces. 2 NORMATIVE REFERENCES The following normative documents contain provisions which, through reference in this text, constitute provisions of this International Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC maintain registers of currently valid International Standards. ISO/IEC 2022, "Information technology - Character code structure and extension techniques". ISO 4217, "Codes for the representation of currencies and funds". ISO 8601, "Data elements and interchange formats - Information interchange - Representation of dates and times". ISO/IEC 9945-2:1993, "Information technology - Portable Operating System Interface (POSIX) Part 2: Shell and Utilities". ISO/IEC 10646:1997, "Information technology - Universal Multiple-Octet Coded Character Set (UCS), including Cor.1 and AMD 1-9". ISO/IEC 14651, "Information technology - International string ordering - Method for comparing character strings and description of a default tailorable ordering". 3 TERMS, DEFINITIONS AND NOTATIONS 3.1 Terms and definitions For the purposes of this International Standard, the terms and definitions given in the following apply. 3.1.1 byte: An individually addressable unit of data storage that is equal to or larger than an octet, used to store a character or a portion of a character. A byte is composed of a contiguous sequence of bits, the number of which is application defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. 3.1.2 character: A member of a set of elements used for the organization, control or representation of data. 3.1.3 coded character: A sequence of one or more bytes representing a single character. 3.1.4 text file: A file that contains characters organized into one or more lines. 3.1.5 cultural convention: A data item for computer use that may vary dependent on language, territory, or other cultural circumstances. 3.1.6 FDCC-set: A Set of Formal Definitions of Cultural Conventions. The definition of the subset of a user's information technology environment that depends on language and cultural conventions. Note: the FDCC-set is a superset of the "locale" term in C and POSIX. 3.1.7 charmap: A definition of a mapping between symbolic character names and the encoding for a coded character set" 3.1.8 repertoiremap: A definition of a mapping between symbolic character names and characters for the repertoire of characters used in a FDCC-set, further described in clause 6. 3.1.9 character class: A named set of characters sharing an attribute associated with the name of the class. 3.1.10 printable character: One of the characters included in the "print" character classification of the LC_CTYPE category in the current FDCC-set. 3.1.11 white space: A sequence of one or more characters that belong to the "space" class as defined via the LC_CTYPE category in the current FDCC-set. 3.1.12 collation: The logical ordering of strings according to defined precedence rules. 3.1.13 collating element: The smallest entity used to determine the logical ordering of strings. See collating sequence. A collating element shall consist of either a single character, or two or more characters collating as a single entity. The value of the LC_COLLATE category in the current FDCC-set determines the current set of collating elements. 3.1.14 multicharacter collating element: A sequence of two or more characters that collate as an entity. For example, in some languages two characters are sorted as one letter, this is the case for Danish and Norwegian "aa". 3.1.15 collating sequence: The relative order of collating elements as determined by the setting of the LC_LOCALE category in the current FDCC-set. 3.1.16 equivalence class: A set of collating elements with the same primary collation weight. Elements in an equivalence class are typically elements that naturally group together, such as all accented letters based on the same letter. The collation order of elements within an equivalence class is determined by the weights assigned on any subsequent levels after the primary weight. 3.1.17 affirmative response: A string conforming to the definition of LC_MESSAGES category keyword "yesexpr". 3.1.18 negative response: A string conforming to the definition of LC_MESSAGES category keyword "noexpr". 3.2 Notations The following notations and common conventions for specifications apply to this standard: 3.2.1 Format of syntax descriptions In this standard the syntax descriptions for statements are specified in the following way: The format is given in a format string enclosed in double quotes, followed by a number of parameters, separated by a comma. The format of each parameter is given by an escape sequence as follows: %s specifies a string %d specifies an decimal integer %c specifies a character %o specifies an octal integer %x specifies a hexadecimal integer All other characters in the format string except %% specifies a single % \n specifies an end-of-line represent themselves. The notation "..." is used to specify that repetition of the previous specification is optional, and this is done in both the format string and in the parameter list. 3.2.2 Continuation of lines A line in a specification can be continued by placing an escape character as the last visible graphic character on the line; this continuation character shall be discarded from the input. Comment lines shall not be continued on a subsequent line using an escaped . 3.2.3 Ellipses A series of characters in a specification can be represented by three adjacent periods representing an absolute ellipsis symbol ("..."), or the symbols "...." or ".." representing respectively the symbolic decimal ellipsis symbol and the symbolic hexadecimal ellipsis symbol. The ellipsis specification shall be interpreted as meaning that all values between the values preceding and following it represent valid characters. The absolute ellipsis specification is only valid within a single encoded character set. An ellipsis shall be interpreted as including in the list all characters with an encoded value higher than the encoded value of the character preceding the ellipsis and lower than the encoded value of the character following the ellipsis. The absolute ellipsis specification is deprecated, as this is only relevant to FDCC-sets not using symbolic characters. The symbolic ellipsis specifications are only valid between symbolic character names. They shall be interpreted as all the symbolic names that can be generated by either incrementing the first symbolic names decimally or hexadecimally (corresponding to "...." or ".." respectively) until the symbolic character name is less or equal the second symbolic character name. Examples: The use of the hexadecimal symbolic ellipsis in .. generates the symbolic character names , , , , , , and in that sequence. The use of the decimal symbolic ellipsis in .. generates the symbolic character names , , , , , and in that sequence. 4 FDCC-set A FDCC-set is the definition of the subset of a user's information technology environment that depends on language and cultural conventions. It is made up from one or more categories. Each category is identified by its name and controls specific aspects of the behaviour of components of the system. This standard defines following categories: LC_CTYPE Character classification, case conversion and code transformation. LC_COLLATE Collation order. LC_TIME Date and time formats. LC_NUMERIC Numeric, non-monetary formatting. LC_MONETARY Monetary formatting. LC_MESSAGES Formats of informative and diagnostic messages and interactive responses. LC_PAPER Paper format LC_NAME Format of writing personal names LC_ADDRESS Format of postal addresses LC_TELEPHONE Format for telephone numbers, and other telephone information LC_MEASUREMENT Information on measurement system LC_VERSIONS Versions and status of categories In future editions of this standards further categories may be added. Other category names beginning with the 3 characters "LC_" are intended for future standardization, except for category names beginning with the five letters "LC_X_" which use is application defined. An implementation should thus use category names beginning with the five letters "LC_X_" to avoid clashes with future standardized categories. This standard also defines an FDCC-set named "i18n" with values for each of the above categories. 4.1 FDCC-set Definition FDCC-sets are described with the format presented in this subclause. For the purposes of this standard, the text is referred to as the FDCC-set definition text or FDCC-set source text. The FDCC-set definition text shall contain one or more FDCC- set category source definitions, and shall not contain more than one definition for the same FDCC-set category. If the text contains source definitions for more than one category, application-defined categories, if present, shall appear after the categories defined by this clause. A category source definition shall contain either the definition of a category or a copy directive. In the event that some of the information for a FDCC-set category, as specified in this standard, is missing from the FDCC-set source definition, the behaviour of that category, if it is referenced, is unspecified. A FDCC-set category is the normal way of specifying a single FDCC. A category source definition shall consist of a category header, a category body, and a category trailer. A category header shall consist of the character string naming of the category, beginning with the characters "LC_". The category trailer shall consist of the string "END", followed by one or more "blank"s and the string used in the corresponding category header. The category body shall consist of one or more lines of text. Each line shall contain an identifier, optionally followed by one or more operands. Identifiers shall be either keywords, identifying a particular FDCC, or collating elements, or script symbols, or transliteration statements. In addition to the keywords defined in this standard, the source can contain application-defined keywords. Each keyword within a category shall have a unique name (i.e., two categories can have a commonly-named keyword); no keyword shall start with the characters "LC_". Identifiers shall be separated from the operands by one or more "blank"s. Operands shall be characters, collating elements, script symbols, or strings of characters. Strings shall be enclosed in double-quotes. Literal double-quotes within strings shall be preceded by the , described below. When a keyword is followed by more than one operand, the operands shall be separated by semicolons; "blank"s shall be allowed before and/or after a semicolon. 4.1.1 Character representation Individual characters, characters in strings, and collating elements shall be represented using symbolic names, UCS notation or characters themselves, or as octal, hexadecimal, or decimal constants as defined below. When constant notation is used, the resultant FDCC-set definitions need not be portable between systems. (0) The left angle bracket (<) is a reserved symbol, denoting the start of a symbolic name; when used to represent itself it shall be preceded by the escape character. (1) A character can be represented via a symbolic name, enclosed within angle brackets (< and >). The symbolic name, including the angle brackets, shall exactly match a symbolic name defined in a charmap or a repertoiremap to be used, and shall be replaced by a character value determined from the value associated with the symbolic name in the charmap or a value associated via a repertoiremap. Repertoiremaps have predefined symbolic names for UCS characters, see clause 6. Use of the escape character or a right angle bracket within a symbolic name shall be invalid unless the character is preceded by the escape character. Example: ; "" The items (2), (3), (4) and (5) are deprecated and are retained for compatibility with the POSIX standard. FDCC-sets should be specified in a coded character set independent way, using symbolic names. To make actual use of the FDCC-set, it shall be used together with charmaps and/or repertoiremaps, so that the symbolic character names can be resolved into the actual character encoding used. (2) A character can be represented by the character itself, in which case the value of the character is application- defined. Within a string, the double-quote character, the escape character, and the right angle bracket character shall be escaped (preceded by the escape character) to be interpreted as the character itself. Outside strings, the characters , ; < > escape_char shall be escaped to be interpreted as the character itself Example: c "May" (3) A character can be represented as an octal constant. An octal constant shall be specified as the escape character followed by two or more octal digits. Each constant shall represent a byte value. Example: \143; \347; "\115" (4) A character can be represented as a hexadecimal constant. A hexadecimal constant shall be specified as the escape character followed by an x followed by two or more hexadecimal digits. Each constant shall represent a byte value. Example: \x63;\xe7; (5) A character can be represented as a decimal constant. A decimal constant shall be specified as the escape character followed by a d followed by two or more decimal digits. Each constant shall represent a byte value. Example: \d99; \d231; (6) Multibyte characters can be represented by concatenated constants specified in byte order with the last constant specifying the least significant byte of the character. Concatenated constants can include a mix of the above character representations. Example: \143\xe7; "\115\xe7\d171" Only characters existing in the character set for which the FDCC-set definition is created shall be specified, whether using symbolic names, the characters themselves, or octal, decimal, or hexadecimal constants. If a charmap is present, only characters defined in the charmap can be specified using octal, decimal, or hexadecimal constants. Symbolic names not present in the charmap can be specified and shall be ignored, as specified under item (1) above. 4.1.2 Pre-category statements In a FDCC-set the following statements can precede category specifications, and they apply to all categories in the specified FDCC-set. 4.1.2.1 comment_char The following line in a FDCC-set modifies the comment character. It shall have the following format, starting in column 1: "comment_char %c\n", The comment character shall default to the number-sign (#). All examples this standard use "%" as the , except where otherwise noted. Blank lines and lines containing the in the first position, and the remainder of a line with a occurring where a syntactic semicolon may occur, shall be ignored. 4.1.2.2 escape_char The following line in a FDCC-set modifies the escape character to be used in the text. It shall have the following format, starting in column 1: "escape_char %c\n", The escape character shall default to backslash "\". All examples in this standard uses "/" as the escape character, except where otherwise noted. 4.1.2.3 repertoiremap The following line in a FDCC-set specifies the name of a repertoiremap used to define the symbolic character names in the FDCC-set. There may be at most one "repertoiremap" line. It shall have the following format, starting in column 1: "repertoiremap %s\n", 4.1.2.4 charmap The following line in a FDCC-set specifies the name of a charmap which may be used with the FDCC-set. It shall have the following format, starting in column 1: "charmap %s\n", There may be more than one charmap specification in a FDCC- set. For the actual use of a FDCC-set, at most one charmap may be in use, and this may be different from any charmap specified with the "charmap" line. The "charmap" keyword is intended to provide information on which charmaps are supposed to be used with the FDCC-set, but other charmaps may also be applicable. 4.2 LC_CTYPE The LC_CTYPE category defines character classification, case conversion, character transformation, and other character attribute mappings. Ellipsises and symbolic ellipsises as defined in clause 3.2.3 may be used to specify a list of characters. Support for the portable character set is required. Example: \x30:...;\x39; includes in the character class all characters with encoded values between the endpoints. 4.2.1 Basic keywords The following keywords shall be defined. In the descriptions, the term "automatically included" means that it shall not be an error to either include the referenced characters or to omit them; the interpreting system shall provide them if missing and accept them silently if present. copy Specify the name of an existing FDCC-set to be used as the source for the definition of this category. If this keyword is specified, no other keyword shall be specified. upper Define characters to be classified as uppercase letters. No character specified for the keywords cntrl, digit, punct, or space shall be specified. The uppercase letters A through Z of the portable character set, shall automatically belong to this class, with application-defined character values. The keyword may be omitted. lower Define characters to be classified as lowercase letters. No character specified for the keywords cntrl, digit, punct, or space shall be specified. The lowercase letters a through z of the portable character set, shall automatically belong to this class, with application-defined character values. The keyword my be omitted. alpha Define characters to be classified as letters or other characters used in words of natural languages such as syllabic or ideographic characters. No character specified for the keywords cntrl, digit, punct, or space shall be specified. In addition, characters classified as either upper or lower shall automatically belong to this class. The keyword may be omitted. digit Define the characters to be classified as numeric digits. Digits corresponding to the values 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9 can be specified in groups of 10 digits, and in ascending order of the values they represent. The digits of the portable character set are automatically included. If this keyword is not specified, the digits 0 through 9 of the portable character set shall automatically belong to this class, with application-defined character values. The keyword may be omitted. outdigit Define the characters to be classified as numeric digits for output. Digits corresponding to the values 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9 can be specified, and in ascending order of the values they represent. If this keyword is not specified, the digits 0 through 9 of the portable character set shall automatically belong to this class, with application-defined character values. The keyword may be omitted. space Define characters to be classified as white-space characters, for to find syntactical boundaries. No character specified for the keywords upper, lower, alpha, digit, graph, or xdigit shall be specified. If this keyword is not specified, the characters , , , , , and , shall automatically belong to this class, with application-defined character values. Any characters included in the class blank shall be automatically included. The keyword may be omitted. cntrl Define characters to be classified as control characters. No character specified for the keywords upper, lower, alpha, digit, punct, graph, print, or xdigit shall be specified. The keyword shall be specified. punct Define characters to be classified as punctuation characters. No character specified for the keywords upper, lower, alpha, digit, cntrl, xdigit, or as the character shall be specified. The keyword shall be specified. graph Define characters to be classified as printable characters, not including the character. If this keyword is not specified, characters specified for the keywords upper, lower, alpha, digit, xdigit, and punct shall belong to this character class. No character specified for the keyword cntrl shall be specified. print Define characters to be classified as printable characters, including the character. If this keyword is not provided, characters specified for the keywords upper, lower, alpha, digit, xdigit, punct, graph, and the character shall belong to this character class. No character specified for the keyword cntrl shall be specified. xdigit Define the characters to be classified as hexadecimal digits. Only the characters defined for the class digit shall be specified, in ascending sequence by numerical value, followed by one or more sets of six characters representing the hexadecimal digits 10 through 15, with each set in ascending order (for example A, B, C, D, E, F, a, b, c, d, e, f). If this keyword is not specified, the digits 0 through 9, the uppercase letters A through F, and the lowercase letters a through f, shall automatically belong to this class, with applicat- ion-defined character values. blank Define characters to be classified as "blank" characters. If this keyword is unspecified, the characters and , with application-defined character values, shall belong to this character class. toupper Define the mapping of lowercase letters to uppercase letters. The operand shall consist of character pairs, separated by semicolons. The characters in each character pair shall be separated by a comma and the pair enclosed by parentheses. The first character in each pair shall be the lowercase letter, the second the corresponding uppercase letter. Only characters specified for the keywords lower and upper shall be specified. If this keyword is not specified, the lowercase letters a through z, and their corresponding uppercase letters A through Z, shall automatically be included, with application-defined character values. tolower Define the mapping of uppercase letters to lowercase letters. The operand shall consist of character pairs, separated by semicolons. The characters in each character pair are separated by a comma and the pair enclosed by parentheses. The first character in each pair shall be the uppercase letter, the second the corresponding lowercase letter. Only characters specified for the keywords lower and upper shall be specified. If this keyword is specified, the uppercase letters A through Z, and their correspon- ding lowercase letter, shall be specified. If this keyword is not specified, the mapping shall be the reverse mapping of the one specified for toupper. class Define characters to be classified as characters in the class defined with the first operand, which is a string. The string shall only contain letters, digits and and form the portable character set. The following operands are characters. This keyword is optional. The keyword can only be specified once per named class. Defined classes are: left_to_right Left-to-right directionality, for example Latin letters. right_to_left Right-to-left directionality, for example Hebrew letters. num_terminator Numeric terminator required for determining the end of a number. num_separator numbers separator characters that can separate numbers written with any of the characters in the digit class. segment_separator Segment separator characters, that delimits segments, normally part of a line, with specific directionality. block_separator Block separator characters, that delimits larger blocks of text with a specific directionality. direction_control Direction control characters, such as the characters listed in ISO/IEC 10646-1:1993 annex D.1.3. sym_swap_layout Symmetrical swap layout characters, such as the characters listed in ISO/IEC 10646-1:1993 annex D.2.2 char_shape_selector Character shaping selector characters, such as the characters listed in ISO/IEC 10646-1:1993 annex D.2.3 num_shape_selector Numeric shaping selector characters, such as the characters listed in ISO/IEC 10646-1:1993 annex D.2.4 non_spacing Characters to form composite graphic symbols, such as characters listed in ISO/IEC 10646:1993 annex B.1. non_spacing_level3 Characters to form composite graphic symbols, that may also be represented by other characters, such as characters listed in ISO/IEC 10646-1:1993 annex B.2. normal_connect Characters that connect both to the left and to the right r_connect Characters that connect only to their right. no_connect Characters that do not connect and cannot be overridden. no_connect-space Characters that may be overridden, but do not connect. vowel_connect Connectable vowels. special1 Characters that need special handling. special2 Characters that need special handling. special3 Characters that need special handling. The class names "upper", "lower", "alpha", "digit", "space", "cntrl", "punct", "graph", "print", "xdigit", and "blank" are taken to mean the classes defined by the respective keywords. map Define the mapping of characters. The first operand is a string, defining the name of the mapping. The string shall only contain letters, digits and and form the portable character set. The following operands shall consist of character pairs, separated by semicolons. The characters in each character pair shall be separated by a comma and the pair enclosed by parentheses. The first character in each pair shall be the character to map from, the second the corresponding character to map to. This keyword is optional. The keyword can only be specified once per named mapping. Defined mappings are: tosymmetric Characters to be switched for eachother in bidirectional text, for example characters listed in ISO/IEC 10646-1 Annex C. For each pair also the mapping form the second operand to the first operand is also defined. The mapping names "toupper", and "tolower" are taken to mean the mapping defined by the respective keywords. Table 1 shows the allowed character class combinations. Table 1: Valid Character Class Combinations Class upper lower alpha digit space cntrl punct graph print xdigit blank upper + A x x x x A A + x lower + A x x x x A A + x alpha + + x x x x A A + x digit x x x x x x A A A x space x x x x + * * * x + cntrl x x x x + x x x x + punct x x x x + x A A x + graph + + + + + x + A + + print + + + + + x + + + + xdigit + + + + x x x A A x blank x x x x A + * * * x NOTES: Note 1: Explanation of codes: A Automatically included; see text + Permitted x Mutually exclusive * See note 2 Note 2: The character, which is part of the space and blank class, cannot belong to punct or graph, but automatically shall belong to the print class. Other space or blank characters can be classified as punct, graph, and/or print. 4.2.2 Character string transliteration The following keywords may be used to transliterate strings. The transliteration may for example be from the Cyrillic script to the Latin script. Transliteration is often language dependent, and the language to be transliterated to is identified with the FDCC-set, which may also be used to identify a specific language to be transliterated from. Transliteration of an incoming character string to a character string in a FDCC-set can be specified with the following keywords and transliteration statements. translit_start The "translit_start" keyword is followed by one or more transliteration statements assigning character transliteration values to transliterating elements, and include statements copying transliteration specifications from other FDCC-sets. translit_end The end of the transliteration statements. include The name of the FDCC-set in text form to transliterate from, and the repertoiremap for the FDCC-set to be used for the definition of the transliteration statements. Other transliteration statements may follow to replace specification of the copied FDCC-set. This keyword is optional. default_missing defines one or more characters to be used if no transliteration statement can be applied to a input . 4.2.2.1 Transliteration statements The "translit_start" keyword may be followed by transliteration statements. The syntax for a transliteration statement is: "%s %s;%s;...;%s\n",,, ,... Each shall consist of one or more characters (in any of the forms defined in 4.1.1). The in terms of number of characters that match the input string is the one selected for transliteration. The order the is defined in, defines the precedence of transliterations. The first that satisfies the transliteration (by for example having characters that are all in the coded character set that is transformed into and having the desired string length) is chosen. Note: For this match in the list of it is expected that a repertoire describing which characters to be present in the resulting transformed string be available to the transliteration API. If more than one transliteration statement is given for a given this is an error, unless it is specifically allowed by the utility handling the FDCC-set - then a warning is given and the last transliteration statement is assumed. 4.2.2.2 "include" keyword The "include" keyword specifies a set of transliteration statements in text form to be included in the current transliteration. The syntax of the "include" statement is: "include %s;%s\n", , is a string identifying the FDCC-set to be included from. is a string identifying the repertoiremap used in the FDCC-set being included, and is used to map character specifications from the specified FDCC-set into the current FDCC-set. 4.2.2.3 Example of use of transliteration translit_start include "de_DE";"de_repmap" default_missing ;;;"" ; translit_end The "translit_start" keyword introduces the transliteration section in the LC_CTYPE category. The "include" keyword specifies that the FDCC-set "de_DE" is copied and that the repertoiremap "de_repmap" is used to define the symbolic character names in the FDCC-set "de_DE". The "default_missing" keyword introduces the character sequence "" as the string to transform into for input characters that cannot be transformed into other strings, because no transliteration statement is applicable to the character. The next 3 lines are transliteration statements. The first transliteration statement defines a number of transliterations for the LATIN LETTER AE, including into LATIN LETTER A WITH DIAERESIS, GREEK LETTER EPSILON, the two Latin letters A and E, and finally the LATIN LETTER E. The second transliteration statement defines transliteration of the LATIN LETTER S into GREEK LETTER SIGMA, and CYRILLIC LETTER ES. The third transliteration statement transliterates the two Latin letters K and O into the Japanese Hiragana character KO. The transliteration sections is terminated via the "translit_end" keyword in the above example. 4.2.3 "i18n" LC_CTYPE category The "i18n" FDCC-set for the LC_CTYPE is defined as follows: LC_CTYPE % The following is the 14652 i18n fdcc-set LC_CTYPE category. % It covers ISO/IEC 10646-1 including Cor.1 and AMD 1 thru 9 upper / ..;..;..;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;..;..;/ ;;..;;;;;;/ ;;;;;;..;/ ;;;;;;;;/ ;;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ..;;;;..;..; / ..;..;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;..;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;..;/ ..;..;..;..; ;/ ;;;..;..;/ ..;..;..;..;/ ..;..;..;.. % lower / ..;..;..;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;..;/ ;;;;;;;/ ..;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ..;..;..;;.. ;/ ..;..;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;..;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;..;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ;;;;;;;;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;..;..;/ ;;..;;;..;/ ;;..;..;;;;/ ;..;.. % alpha / ..;..;;;..;/ ..;..;..;..;/ ..;..;;/ ;..;;..;..;/ ..;;;;;..;/ ..;..;..;..;/ ..;;;;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;/ ..;..;/ ..;..;;..;/ ..;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;;..;/ ..;..;..;..;/ ..;..;/ ;..;..;..;/ ..;..;..;..;/ ..;..;..;..;/ ;;/ ..;..;;..;/ ..;..;..;..;/ ..;..;..;;;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;;..;..;/ ..;..;..;..;/ ..;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;/ ..;..;/ ..;;..;;;/ ..;..;..;;;/ ..;..;..;..;/ ..;;..;..;/ ;..;;;;..;/ ..;/ ..;..;..;;/ ..;..;;/ ..;..;/ ..;..;/ ..;..;/ ..;/ ..;..;..;..;/ ..;..;;..;/ ..;/ ..;/ ;;..;;..;/ ..;..;;;;;/ ;..;;;..;;/ ..;;;;..;/ ..;..;..;.. % digit / ..;..;..;..;/ ..;..;..;..;/ <0>;..;..;..;..;/ ..;..;..;;.. ;/ ;;;;;;/ ;;; % outdigit .. % space ;..;;..;/ ..; % cntrl ..;.. % punct / ..;..;..;/ ..;..;;;;..; / ;;..;;;;;/ ;;;;;;..;/ ..;;..;..;;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;;..;.. ;/ ..;..;..;..;/ ..;..;..;..;/ ..;;..;;..;/ ..;..;;;;;;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;;;..;/ ..;..;;..;.. ;/ ..;..;..;;.. ;/ ..;..; % graph / ..;..;..;/ ..;..;..;..;/ ;;;;;;..;;/ ..;..;..;;;; / ;..;..;..;/ ..;..;..;;;/ ;;..;..;;;/ ..;..;..;;/ ..;..;..;/ ..;..;..;;;; / ..;..;..;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;..;;;/ ..;..;;..;;/ ..;;;..;;;;/ ..;..;;..;;; / ..;..;;;;;/ ;;;..;;;..;/ ..;;..;..;.. ;/ ;..;..;..;/ ;;..;..;..;/ ..;;;..;..;/ ..;;;..;..;/ ;;..;..;;;/ ..;;;;;..;/ ..;;;..;..;/ ..;;;;;;;;/ ..;..;..;..;/ ..;..;;..;.. ;/ ..;..;..;..;/ ..;..;..;..;/ ;;;;..;;;/ ..;..;..;..;/ ..;..;..;..;/ ;;;;;..;;;/ ..;..;..;..;/ ..;..;..;;;; / ..;..;..;;;; / ;;;;..;..;/ ..;;;;;..;/ ..;..;;..;.. ;/ ;;/ ..;..;..;/ ..;..;;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;;;;..;..; / ..;..;..;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;..;..; ;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;..;..; ;/ ..;;..;..;.. ;/ ..;..;..;;.. ;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;;;;;;/ ..;..;..;..;/ ..;..;..;..;/ ..;..;..;;.. ;/ ;..;..;..;/ ..;..;..;..;/ ..; % % "print" is by default "graph", and the character % xdigit ..;..;.. % blank ;;..;..; % toupper / (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,) tolower / (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,);(,);(,);(,);/ (,) % right_to_left / ..;..;..;/ ..;..;..;;;; / ..;..;;..;/ ..;..;..;..;/ % class "num_terminator";<:>; class "num_separator";<:>; class "direction_control";;;.. class "sym_swap_layout";; class "char_shape_selector";; class "num_shape_selector";; class "non_spacing"; / ..; ..; ..;/ ..;..;..;/ ..;;;;;..;;/ ..;;;..;..;; / ..;..;;;..;; / ..;;;..;;;;/ ;;..;;;..;/ ;;..;;..;..; / ..;..;;..;;; / ..;;;;;..;/ ..;..;;..;.. ;/ ..;..;;;;;/ ..;..;..;;;/ ;;..;..;..;; / ;..;..;;..;/ ;;..;;;;;;/ ;;..;..;;..; / ;..;..;;..;/ ;; % class "non_spacing_level3"; / ..;..;..;..;/ ..;..;..;;/ ;;;;;;;/ ;;;;;;;;;/ ;;;;..;; % map "tosymmetric"; / (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,); (,) END LC_CTYPE 4.3 LC_COLLATE A collation sequence definition defines the relative order between collating elements (characters and multicharacter collating elements) in the FDCC-set. This order is expressed in terms of collation values; i.e., by assigning each element one or more collation values (also known as collation weights). This does not imply that applications shall assign such values, but that ordering of strings using the resultant collation definition in the FDCC-set shall behave as if such assignment is done and used in the collation process. The collation sequence definition shall be used by regular expressions, pattern matching, and sorting. The following capabilities are provided: (1) Multicharacter collating elements. Specification of multicharacter collating elements (i.e., sequences of two or more characters to be collated as an entity). (2) User-defined ordering of collating elements. Each collating element shall be assigned a collation value defining its order in the character (or basic) collation sequence. This ordering is used by regular expressions and pattern matching and, unless collation weights are explicitly specified, also as the collation weight to be used in sorting. (3) Multiple weights and equivalence classes. Collating elements can be assigned one or more (up to the limit (COLL_WEIGHTS_MAX)) collating weights for use in sorting. The first weight is hereafter referred to as the primary weight. (4) One-to Many mapping. A single character is mapped into a string of collating elements. (5) Many-to-Many substitution. A string of one or more characters is substituted by another string (or an empty string, i.e., the character or characters shall be ignored for collation purposes). (6) Equivalence class definition. Two or more collating elements have the same collation value (primary weight). (7) Ordering by weights. When two strings are compared to determine their relative order, the two strings are first broken up into a series of collating elements, and each successive pair of elements are compared according to the relative primary weights for the elements. If equal, and more than one weight has been assigned, then the pairs of collating elements are recompared according to the relative subsequent weights, until either a pair of collating elements compare unequal or the weights are exhausted. (8) Per script ordering rules. Some cultures order some scripts in a different direction than other scripts, for example in French cultures the Latin script is ordered backwards on the level handling accents, while the Cyrillic script may be ordered forwards. (9) Easy reordering of characters. ISO/IEC 14651 has a template for collation specification that with just a few modifications can be culturally correct for a specific culture. Here the "reorder-after" keyword gives a convenient way to modify a FDCC-set template. (10) Easy reordering of scripts. The template in ISO/IEC 14651 gives an ordering of the scripts that may not be culturally acceptable in certain cultures. The keyword "reorder-script-after" gives a convenient way to modify the order of scripts in a FDCC-set template. The following keywords shall be defined in a collation sequence definition. Some of them are described in detail in the following subclauses. copy Specify the name of an existing FDCC-set to be used as the source for the definition of this category. If this keyword is specified, only the "reorder-after", "reorder-end", "reorder-scripts- after" and "reorder-scripts-end" keywords may also be specified. The FDCC-set shall be copied in source form. coll_weight_max Define as a decimal number the number of collation levels that an interpreting system needs to support, this value is elsewhere referred as the COLL_WEIGHT_MAX limit. The minimum value is 7. script Define a script symbol representing a set of collation order statements. This keyword is optional. collating-element Define a collating-element symbol representing a multicharacter collating element. This keyword is optional. collating-symbol Define a collating symbol for use in collation order statements. This keyword is optional. order_start Define collation rules. This statement is followed by one or more collation order statements, assigning character collation values and collation weights to collating elements. order_end Specify the end of the collation-order statements. reorder-after Redefine collating rules. Specify after which collating element the redefinition of collation order shall take order. This state- ment is followed by one or more collation order statements, reassigning character collation values and collation weights to collating elements. reorder-end Specify the end of the "reorder-after" collating order statements. reorder-script-after Redefine the order of scripts. This statement is followed by one or more script symbols, reassigning character collation values and collation weights to collating elements. reorder-script-end Specify the end of the "reorder-scripts" script order statements. Toggling keywords: define defines a toggle undef undefines a toggle ifdef tests a toggle, and if defined uses the following statements ifndef tests a toggle, and if undefined uses the following statements else uses the following statements if no preceding toggling statements have been used elif tests a toggle, and uses the following statements if no preceding toggling statements have been used, and the toggle is defined endif terminates set of toggling statements 4.3.1 Collation statements The "order_start" and "replace-after" keyword shall be followed by collating statements. The syntax for the collating statements is "%s %s;%s;...;%s\n",,,,... Each collating-element shall consist of either a character (in any of the forms defined in 4.1.1), a , a , an ellipsis, or the special symbol UNDEFINED. The order in which collating elements are specified determines the character collation sequence, such that each collating element shall compare less than the elements following it. The NUL character shall compare lower than any other character. A shall be used to specify multicharacter collating elements, and indicates that the character sequence specified via the is to be collated as a unit and in the relative order specified by its place. A shall be used to define a position in the relative order for use in weights. The ellipsis symbol ("...") specifies that a sequence of characters shall collate according to their encoded character values. It shall be interpreted as indicating that all characters with a coded character set value higher than the value of the character in the preceding line, and lower than the coded character set value for the character in the following line, in the current coded character set, shall be placed in the character collation order between the previous and the following character in ascending order according to their coded character set values. An initial ellipsis shall be interpreted as if the preceding line specified the NUL character, and a trailing ellipsis as if the following line specified the highest coded character set value in the current coded character set. An ellipsis shall be treated as invalid if the preceding or following lines do not specify characters in the current coded character set. The use of the ellipsis symbol ties the definition to a specific coded character set and may preclude the definition from being portable between applications. Symbolic ellipses may be used as the ellipses symbol, but generating symbolic character names, and thus have a better chance of portability between applications. The symbolic ellipsises (".." or "....") specifies that a sequence collating statements. It shall be interpreted as indicating that all characters with symbolic names higher then the symbolic name of the character in the preceding line, and lower than the coded character set value for the character in the following line, shall be placed in the character collation order between the previous and the following character in ascending order. The symbol UNDEFINED shall be interpreted as including all coded character set values not specified explicitly or via the ellipsis or one of the symbolic elipsises symbols. Such characters shall be inserted in the character collation order at the point indicated by the symbol, and in ascending order according to their coded character set values. If no UNDEFINED symbol is specified, and the current coded character set contains characters not specified in this clause, the utility shall issue a warning message and place such characters at the end of the character collation order. The optional operands for each collation-element shall be used to define the primary, secondary, or subsequent weights for the collating element. The first operand specifies the relative primary weight, the second the relative secondary weight, and so on. Two or more collation-elements can be assigned the same weight; they belong to the same equivalence class if they have the same primary weight. Collation shall behave as if, for each weight level, IGNOREd elements are removed. Then each successive pair of elements shall be compared according to the relative weights for the elements. If the two strings compare equal, the process shall be repeated for the next weight level, up to the limit "COLL_- WEIGHTS_MAX" . Weights shall be expressed as characters (in any of the forms specified here), s, s, an ellipsis, or the special symbol IGNORE. A single character, a , or a shall represent the relative order in the character collating sequence of the character or symbol, rather than the character or characters themselves. One-to-many mapping is indicated by specifying two or more concatenated characters or symbolic names. Thus, if the character is given the string as a weight, comparisons shall be performed as if all occurrences of the character are replaced by . If it is desirable to define and as an equivalence class, then a collating-element must be defined for the string "ss", as in the example below. All characters specified via an ellipsis shall by default be assigned unique weights, equal to the relative order of characters. Characters specified via an explicit or implicit UNDEFINED special symbol shall by default be assigned the same primary weight (i.e., belong to the same equivalence class). An ellipsis symbol as a weight shall be interpreted to mean that each character in the sequence shall have unique weights, equal to the relative order of their character in the character collation sequence. Secondary and subsequent weights have unique values. The use of the ellipsis as a weight shall be treated as an error if the collating element is neither an ellipsis nor the special symbol UNDEFINED. The special keyword IGNORE as a weight shall indicate that when strings are compared using the weights at the level where IGNORE is specified, the collating element shall be ignored; i.e., as if the string did not contain the collating element. In regular expressions and pattern matching, all characters that are IGNOREd in their primary weight form an equivalence class. A occurring where the delimiter ";" may occur, terminates the collating statement. An empty operand shall be interpreted as the collating-element itself. For example, the collation statement ; is equal to An ellipsis (absolute or symbolic) can be used as an operand if the collating-element was an ellipsis, and shall be interpreted as the value of each character defined by the ellipsis. Example: collating-element from collating-element from order_start forward;backward UNDEFINED IGNORE;IGNORE ; ... ; ; ; ; ; ; ; ; ; order_end This example is interpreted as follows: (1) The UNDEFINED means that all characters not specified in this definition (explicitly or via the ellipsis) shall be ignored. (2) defines the first collating weight, and thus the lowest weight in this example. (3) All characters between and shall have the same primary equivalence class and individual secondary weights based on their ordinal encoded values. (4) All characters based on the upper or lowercase character "a" belong to the same primary equivalence class. (5) The multicharacter collating element is represented by the collating symbol and belongs to the same primary equivalence class as the multicharacter collating element . (6) The collating element has two weights on the primary level, and it is in the same primary equivalence class as two consecutive -es; on the secondary level the collating element has two weights of the equivalence class . 4.3.2 "copy" keyword This keyword specifies the name of an existing FDCC-set to be used as the source for the definition of this category. The syntax is "copy %s\n", The shall consist of one or more characters (in any of the forms defined in 4.1.1). If this keyword is specified, only the "reorder-after", "reorder-end", "reorder- scripts-after" and "reorder-scripts-end" keywords may also be specified. The FDCC-set shall be copied in source form. 4.3.3 "col_weight_max" keyword This keyword defines as a decimal number the number of collation levels that an interpreting system needs to support, this value is elsewhere referred as the COLL_WEIGHT_MAX limit. The minimum value is 7. The syntax is "col_weight_max %d\n", 4.3.4 "script" keyword This keyword shall be used to define symbols for use in script related statements; such as the "order_start", and "reorder- scripts-after" keywords and script-reordering statements. The syntax is "script %s\n", The shall be a symbolic name, enclosed between angle brackets (< and >), and shall not duplicate any symbolic name in the current charmap (if any), or any other symbolic name defined in this collation definition. A defined via this keyword is only defined with the LC_COLLATE category. Example: script script 4.3.5 "collating-element" keyword In addition to the collating elements in the character set, the collating-element keyword shall be used to define multicharacter collating elements. The syntax is "collating-element %s from %s\n",, The operand shall be a symbolic name, enclosed between angle brackets (< and >), and shall not duplicate any symbolic name in the current charmap or repertoiremap file (if any), or any other symbolic name defined in this collation definition. The string operand shall be a string of two or more characters that shall collate as an entity. A defined via this keyword is only defined with the LC_COLLATE category. Example with ISO/IEC 6937: collating-element from collating-element from collating-element from 4.3.6 "collating-symbol" keyword This keyword shall be used to define symbols for use in collation sequence statements; e.g., between the order_start and the order_end keywords. The syntax is "collating-symbol %s\n", The shall be a symbolic name, enclosed between angle brackets (< and >), and shall not duplicate any symbolic name in the current charmap (if any), or any other symbolic name defined in this collation definition. A defined via this keyword is only defined with the LC_COLLATE category. Example: collating-symbol collating-symbol 4.3.7 "symbol-equivalence" keyword This keyword shall be used to define symbols for use in collation sequence statements; and assign the same weight as another defined symbol. The syntax is "symbol-equivalence %s %s\n", , The and shall be symbolic names, enclosed between angle brackets (< and >). shall not duplicate any symbolic name in the current charmap (if any), or any other symbolic name defined in this collation definition. is defined elsewhere in the LC_COLLATE category as a collating- symbol. The use of shall be equivalent to using the defined via this keyword is only defined with the LC_COLLATE category. Example collating-symbol symbol-equivalence 4.3.8 "order_start" keyword The "order_start" keyword shall precede collation order entries and also defines the number of weights for this collation sequence definition, the collation script name and other collation rules. The syntax of the "order_start" keyword has two forms: "order_start %s;%s;...;%s\n", , ... and "order_start %s;%s;...;%s\n", , , ... The operands to the order_start keyword are optional. If present, the operands define rules to be applied when strings are compared. The first operand may be a surrounded by "<" and ">" and the set of collating statements following the "order_start" keyword until the "order_end" keyword are identified with this or another "order_start" keyword is encountered. The remaining number of operands define how many weights each element is assigned; if no operands are present, one forward operand is assumed. If present, the first operand defines rules to be applied when comparing strings using the first (primary) weight; the second when comparing strings using the second weight, and so on. Operands shall be separated by semicolons (;). Each operand shall consist of one or more collation directives, separated by commas (,). If the number or operands exceeds the (COLL_WEIGHTS_MAX) limit, the utility shall issue a warning message. The following directives shall be supported: forward Specifies that the direction of scanning a substring in this script at a given point in a string is done towards the logical end of the string for this weight level. backward Specifies that the direction of scanning a substring in this script at a given point in a string is done towards the logical beginning of the string for this weight level. position Specifies that comparison operations for the weight level will consider the relative position of non-IGNOREd elements in the strings. The string containing a non-IGNOREd element after the fewest IGNOREd collating elements from the start of the compare shall collate first. If both strings contain a non-IGNOREd character in the same relative position, the collating values assigned to the elements shall determine the ordering. In case of equality, subsequent non- IGNOREd characters shall be considered in the same manner. The directives forward and backward are mutually exclusive. Examples: order_start forward;backward order_start ;forward;forward If no operands are specified, a single forward operand shall be assumed. 4.3.9 "order_end" keyword The collating order entries shall be terminated with an order_end keyword. 4.3.10 "reorder-after" keyword The "reorder-after" keyword shall be used to specify a modification to a copied collation specification of an existing FDCC-set. There can be more than one "reorder-after" statement in a collating specification. The syntax shall be: "reorder-after %s\n", The operand shall be a symbolic name, enclosed between angle brackets, and shall be present in the source FDCC-set copied via the "copy" keyword. The "reorder-after" statement is followed by one or more collation statements as described in the "Collating Order" clause (4.3.5), with the exception that the ellipsis symbol (...) shall not be used. Each collation statement reassigns character collation values and collation weights to collating elements existing in the copied collation specification, by removing the collating statement from the copied specification, and inserting the collating element in the collating sequence with the new collation weights after the preceding collating element of the "reorder-after" specification, the first collating element in the collation sequence being the specified on the "reorder-after" statement. A "reorder-after" specification is terminated by another "reorder-after" specification or the "reorder-end" statement. 4.3.10.1 Example of "reorder-after" reorder-after ;; ;; reorder-after ;; ;; ;; ;; ;; ;; ;; ;; reorder-end The example is interpreted as follows (using the "i18nrep" repertoiremap): 1. The collating element is removed from the copied collating sequence and inserted after in the collating sequence with the new weights. The collating element is removed from the copied collating sequence and inserted in the resulting collation sequence after with the new weights. 2. The second "reorder-after" statement terminates the first list of reordering collation identifier entries, and initiates a second list, rearranging the order and weights for the , , , , , and collating elements after the collating symbol in the copied specification. 3. The "reorder-end" statement terminates the second list of reordering entries. 4. Thus for the original sequence ... ( U u ) V v W w X x Y y Z z this example reordering gives ... U u V v W w X x ( Y y ) Z z ( ) 4.3.11 "reorder-end" keyword The "reorder-end" keyword shall specify the end of a list of collating statements, initiated by the "reorder-after" keyword. 4.3.12 "reorder-scripts-after" keyword The "reorder-scripts-after" keyword shall be used to specify a modification to a copied collation specification of an existing FDCC-set. The "reorder-scripts-after" statement is followed by one or more statements consisting of script reordering statements. 4.3.12.1 script reordering statements The script reordering statements rearranges the set of collating entries and changes sorting rules for the set of collating entries identified by a script symbol in a preceding "order_start" statement. Each script reorder statement has the syntax: "%s %s;...%s\n", , , ... The identifies the set of collating entries, and shall be defined via a "script" keyword. The are as described for the "order_start" keyword. Specified replace the specification for the ordering of the script given on the "order_start" statement identified by the . The are optional and not to be changed may be given by empty specifications. The order of the script reordering statements rearranges the assignment of collation entries for the sets of collation entries identified by the to the order that the occur after the "reorder-scripts-after" statement. The script reordering statements are terminated by a "reorder- scripts-end" statement. 4.3.12.2 Example of script reordering copy "i18n" reorder-scripts-after forward;backward;forward;forward,position reorder-scripts-end This example is interpreted as follows: The LC_COLLATE category of the "i18n" FDCC-set is copied. Then a reordering of all collating statements for the scripts and is done, leaving the rest of the scripts as they were in the "i18n" FDCC-set. The script is placed immediately after the script, and the script immediately following the script. The ordering rules are kept as they were in the "i18n" FDCC-set, while the script gets new ordering rules as indicated. The "reorder-scripts-end" keyword terminates the script reordering statements. 4.3.13 "reorder-scripts-end" keyword The "reorder-scripts-end" keyword shall specify the end of a list of script symbols, initiated by the "reorder-scripts- after" keyword. 4.3.14 Toggling keyword statements The toggling keywords "define" and "undef" shall set, respectively unset a toggle. Toggles that are not defined, are regarded as unset. The toggle is a string of characters, in any form as described in clause 4.1.1. The keywords "ifdef", "ifndef", "elif", "else", and "endif" controls the inclusion of LC_COLLATE keywords and statements, as described in the following, and they work in a nesting manner. The toggling keywords are modelled after the precompiler in the C standard. 4.3.14.1 "define" keyword This keyword shall be used to set a toggle, for use with other toggling keywords. The same toggle may occur with more "define" statements. The syntax is "define %s\n", 4.3.14.2 "undef" keyword This keyword shall be used to unset a toggle, for use with other toggling keywords. The same toggle may occur with more "undef" statements. The syntax is "undef %s\n", 4.3.14.3 "ifdef" keyword This keyword shall be used to control the inclusion of the following LC_COLLATE statements, up to a corresponding "elif", "else" or "endif" keyword. If the toggle is set, the statements are used, otherwise they are ignored. The syntax is "ifdef %s\n", 4.3.14.4 "ifndef" keyword This keyword shall be used to control the inclusion of the following LC_COLLATE statements, up to a corresponding "elif", "else" or "endif" keyword. If the toggle is unset, the statements are used, otherwise they are ignored. The syntax is "ifndef %s\n", 4.3.14.5 "elif" keyword This keyword shall be used to control the inclusion of the following LC_COLLATE statements, up to a corresponding "elif", "else" or "endif" keyword. The keyword shall be preceded by a corresponding "ifdef", "ifndef", or "elif" statement and the statement that these keyword statements control. If no preceding "ifdef", "ifndef" or "elif" statement has been used, and if the toggle is set, the statements are used, otherwise they are ignored. The syntax is "elif %s\n", 4.3.14.6 "else" keyword This keyword shall be used to control the inclusion of the following LC_COLLATE statements, up to a corresponding "endif" keyword. The keyword shall be preceded by a corresponding "ifdef", "ifndef", or "elif" statement and the statement that these keyword statements control. If the preceding block of statements were not used, the statements are used, otherwise they are ignored. The syntax is "else\n" 4.3.14.7 "endif" keyword This keyword shall be used to terminate the control of the inclusion of the preceding LC_COLLATE statements. The keyword shall be preceded by a corresponding "ifdef", "ifndef", "elif" or "else" statement. The syntax is "endif\n" 4.3.14.8 Toggling example Here is an example to show the workings of the toggling statements: The "gensort" FDCC-set may be defined as: LC_COLLATE ifdef BACKWARD order_start ;forward;backward;forward;forward,position else order_start ;forward;forward;forward;forward,position endif .... END LC_COLLATE Then the following LC_COLLATE category specification can use the "gensort" specification to create a new LC_COLLATE category: LC_COLLATE define BACKWARD copy "gensort" END LC_COLLATE The example is explained as follows: The LC_COLLATE category in the "gensort" FDCC-set uses the toggle BACKWARD, and as BACKWARD is not set the second "order_start" statement (all "forward") is used. In the second LC_COLLATE category, the BACKWARD toggle is set before copying the first LC_COLLATE category, and thus the first "order_start" statement with 2nd level "backward" is used. 4.3.15 "i18n" LC_COLLATE category The "i18n" LC_COLLATE category is defined as the tailorable template in ISO/IEC 14651. 4.4 LC_MONETARY The LC_MONETARY category defines the rules and symbols that shall be used to format monetary numeric information. The operands are strings. For some keywords, the strings can contain only integers. Keywords that are not provided, string values set to the empty string "", or integer keywords set to -1, shall be used to indicate that the value is unspecified, and then no default is taken. The following keywords shall be defined: copy Specify the name of an existing FDCC-set to be used as the source for the definition of this category. If this keyword is specified, no other keyword shall be specified. int_curr_symbol The international currency symbol. The operand shall be a four character string, with the first three characters containing the alphabetic international currency symbol in accordance with those specified in ISO 4217 (Codes for the representation of currencies and funds). The fourth character shall be the character used to separate the international currency symbol from the monetary quantity. The keyword shall be specified, unless the "copy" keyword is used. currency_symbol The string that shall be used as the local currency symbol. mon_decimal_point The operand is a string containing the symbol that shall be used as the decimal delimiter in monetary formatted quantities. In contexts where other standards limit the mon_decimal_point to a single byte, the result of specifying a multibyte operand is unspecified. The keyword shall be specified, unless the "copy" keyword is used. mon_thousands_sep The operand is a string containing the symbol that shall be used as a separator for groups of digits to the left of the decimal delimiter in formatted monetary quantities. In contexts where other stan- dards limit the mon_thousands_sep to a single byte, the result of specifying a multibyte operand is unspecified. The keyword shall be specified, unless the "copy" keyword is used. mon_grouping Define the size of each group of digits in formatted monetary quantities. The operand is a sequence of integers separated by semicolons. Each integer specifies the number of digits in each group, with the