DOCSLIB.ORG

Internationalizing Javascript Applications Norbert Lindenberg

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Internationalizing Javascript Applications Norbert Lindenberg Internationalizing JavaScript Applications Norbert Lindenberg © Norbert Lindenberg 2013. All rights reserved. Agenda • Unicode support • Collation • Number and date/time formatting • Localizable resources • Message construction 2 JavaScript is… • ECMAScript Language • ECMAScript Internationalization API • Browser: DOM, Navigator, XMLHttpRequest • Server: Node.js • Platforms: Firefox OS, Windows 8, Phonegap • Libraries: jQuery, Dojo, YUI, GWT, Node modules, etc. 3 ECMAScript • Language Speci!cation • Developed by Ecma TC 39 • Language syntax and semantics • Core API: Object, String, Array, RegExp, ... • Edition 5.1 current • Edition 6 expected December 2014 4 ECMAScript • Internationalization API Speci!cation • Developed by Ecma TC 39 + experts • API: Collator, NumberFormat, DateTimeFormat • Edition 1 approved December 2012 • Chrome, Opera, Explorer, Windows shipped; Firefox, Node.js coming • Edition 2 expected December 2014 5 Unicode Unicode support • All text in UTF-16 internally • UTF-8 well supported for transport • Need to identify charset in <script> tags, Content-Type headers • Need to use encodeURIComponent for path and query string components 7 Occupy Wall Street. By @tanlines. Supplementary characters • Characters above U+FFFF • Emoji, rare CJK, ancient scripts, musical symbols, ... • 2 code units in UTF-16 9 Today: UCS-2 or UTF-16? UCS-2: UTF-16: • Regular • Source text expressions conversion • String comparison • URI handling • Case conversion 10 Today: UCS-2 or UTF-16? UCS-2: UTF-16: • Regular • Source text expressions conversion • String comparison • URI handling • Case conversion • DOM, text input, text rendering, XMLHttpRequest 11 ECMAScript 6: UTF-16 • Case conversion for full Unicode • Full Unicode in identi!ers • String accessors for code points • But: no change to low-level string comparison • Planned: New Unicode mode in regular expressions 12 Regular expressions • RegExp in ES5 doesn’t have much Unicode support • No support for Unicode character properties • No support for supplementary characters 13 Regular expressions • CSet (inimino): Character classes with supplementary characters • XRegExp (Steven Levithan and Mathias Bynens): Unicode categories and properties with supplementary characters 14 Unicode normalization • Makes strings be equal that users perceive as equal (more or less) • ä = a ¨ U+00E4 = U+0061 U+0308 • 김 = ; dt U+AE40 = U+1100 U+1175 U+11B7 15 Unicode normalization • ECMAScript 5 “assumes” normalization happens where needed • Reality: applications have to do it • ECMAScript 6: String.prototype.normalize "김".normalize("NFD") → "\u1100\u1175\u11B7" • Libraries available, but not up to date: • unorm (Matsuza) • Richard Ishida’s normalizer 16 北京大学.中国 北京大学.中国 Internationalized domain names • Unicode at user interface • ASCII under the hood • 北京大学.中国 = xn--1lq90ic7fzpc.xn--!qs8s • Main steps: • normalization (as discussed) • punycode (Mathias Bynens has latest) 19 Collation Collation (sorting) • Old: String.prototype.localeCompare • Only string argument • New: Intl.Collator • locales • options • Fixed: String.prototype.localeCompare • With locales and options arguments 21 Locales • BCP 47 language tags • Language, script, country codes • “es”, “en-AU”, “zh-Hans-CN” • Unicode locale extension • “de-u-co-phonebk” • Preference lists • [“mr”, “hi”, “en-IN”] 22 Locale negotiation • BCP 47 Lookup • [“es-GT”, “es-MX”] → “es-GT”, “es”, “es-MX” • Best !t • implementation de!ned • [“es-GT”, “es-MX”] → “es-GT”, “es-MX”, “es” • Unicode extension handled separately 23 Collator extensions • co: collation – phonebook, pinyin, ... • kf: case !rst – upper, lower • kn: numeric sorting 24 Collator options • localeMatcher: lookup, best !t • usage: sort, search • sensitivity: base, accent, case, variant • ignorePunctuation • numeric, caseFirst 25 Non-ECMAScript • Nothing good found (some for Latin only) • Collation is hard • Knowledge of full Unicode character set • Big tables • Send lists that need alphabetic sorting to server 26 Number formatting 27 Number formatting • Old: Number.prototype.toLocaleString • No arguments • New: Intl.NumberFormat • locales • options • Fixed: Number.prototype.toLocaleString • With locales and options arguments 28 NumberFormat extensions • nu: numbering system 29 NumberFormat options • localeMatcher: lookup, best !t • style: decimal, currency, percent • currency: ISO 4217 currency code • currencyDisplay: symbol, code, name • minimum/maximum digits • useGrouping 30 Non-ECMAScript ¤ % ๙ # , ⚑ Globalize + + - + - 250+ Dojo + + - + - 30+ Closure + + + + + 300+ Windows 8 + + + + + 100s iLib + + - + - 10+ ¤: currency formatting. %: percent formatting. ๙: numbering systems. #: digit settings. ,: grouping separator option. ⚑: supported locales. 31 Date and time formatting Date and time formatting • Old: Date.prototype.toLocale[|Date|Time]String • No arguments • New: Intl.DateTimeFormat • locales • options • Fixed: Date.prototype.toLocale[|Date|Time]String • With locales and options arguments 33 DateTimeFormat extensions • ca: calendar • nu: numbering system 34 DateTimeFormat options • localeMatcher: lookup, best !t • timeZone: UTC • hour12 • weekday, era, year, month, day, hour, minute, second, timeZoneName: components • formatMatcher: basic, best !t 35 Non-ECMAScript ca tz ๙ ⚑ Globalize 5+ + - 250+ Dojo 4 - - 30+ Closure + + + 300+ Windows 8 ? - ? ? Moment - - - 50 YUI - - - 50+ ca: calendars. tz: time zones. ๙: numbering systems. ⚑: supported locales. 36 Resources Localizable resources • ECMAScript doesn’t have an I/O system, therefore no standard resource loading • Developers have invented many different mechanisms 38 Representation • At runtime, use object as key-value map • JSON good for transfer; not as source • Localizers need comments • Existing source formats have problems • Java properties !les are not UTF-8 • gettext .po !les encoding is unspeci!ed • YUI uses its own YRB format 39 How dynamic would you like it? • Making resources available to application • Inject strings/objects into JavaScript code • Bundle resources with JavaScript code • Load resource bundles at runtime 40 Injecting strings into JavaScript • Server knows locale when generating JavaScript and HTML • Inject strings or objects directly where needed • E.g., JavaServer Pages Standard Tag Library: <fmt:bundle basename="Messages”> <script> alert("<fmt:message key='HELLO'/>"); </script> </fmt:bundle> 41 Injecting strings into JavaScript • Problems: • Mixes multiple programming languages • Can introduce syntax errors through localization 42 Bundling resources with JavaScript • Server knows locale when serving JS • Bundles resources with JavaScript • Convert to JavaScript/JSON • Concatenate with other JavaScript • Resources: var MyResources = {HELLO: "안녕하세요"}; • Code: alert(MyResources.HELLO); 43 Loading resources at runtime • Locale not known until runtime • Request resources at runtime • Using XMLHttpRequest • By creating script tag • Resources in JSON or module format 44 Loading resources at runtime • Cross-domain support? • Not with XMLHttpRequest • Possible with script tag • Synchronous access? • More convenient programming model • Can lock up browser • BCP 47 support? • Many loaders assume aa-AA format 45 Access to resources in libraries • Dojo • Loading at runtime, synchronous • GWT • Injecting resources (Constant) • Bundling resources (with HTML, Dictionary) • YUI • Bundling resources via module loader 46 Message construction Photo © Den Widhana Message construction • Substitution • {user} went to {city}. • {user}さんは{city}へ行きました。 48 Message construction • Plurals • {user} est allé à {city}. • {user1} et {user2} sont allés à {city}. • 1-6 forms depending on language • {number, plural {one {...} few {...} many {...}}} 49 Message construction • Gender • {user} est allé à {city}. • {user} est allée à {city}. • 1-4 forms depending on language • {gender, select {female {...} male {...} unknown {...}}} 50 Message construction {gender, select { female {num, plural { one {{user1} est allée à {city}.} other {{user1} et {user2} sont allées à {city}.}}} male {num, plural { one {{user1} est allé à {city}.} other {{user1} et {user2} sont allés à {city}.}}} }} 51 Message construction • Google has MessageFormat for Closure environment • Alex Sexton provided standalone version • Mozilla has even more ambitious L20n library 52 Summary • ECMAScript Internationalization API provides core functionality • http://norbertlindenberg.com/2012/12/ ecmascript-internationalization-api/ • Libraries provide more internationalization support than you may think • http://norbertlindenberg.com/2013/10/ javascript-internationalization/ 53.
Load more

Recommended publications
  • IP Sharp Associates NEWSLETTER
    1111111111■■■■■■■■■■■■■■■■• Volume 10 /Number 6 November/December 1982 I. P. SharpAssociates NEWSLETTER In This Issue Conferences 1982 APL Users Meeting 1 APL 82 3 SHARP APL New Release of SHARP APL 4 Applications Software Crosstabulations with XTABS 7 Data Bases New Petrochemical Data Base 8 CHANGES 9 APL APL Terminology 10 Customer Application APS: A Planning System 12 Bulletin Board 1982 APL Users Meeting Atlanta, Houston, Rochester, Washington, Over 700 persons from 22 coun­ the following publications are Wayne 13 tries gathered in Toronto for the available: Publications 1982 APL Users Meeting in Octo­ An Introduction to APL for Book Ends 14 ber. Lively exchanges among at­ Managers ($5.00) Network News tendees and speakers on the prob­ An Introduction to APL for New Dial Access lems, solutions, and applications of Statisticians and Economists Numbers 15 APL highlighted this third inter­ ($70.00) national users' meeting. The most popular sessions were Technical Supplement 41 The use of APL is increasing. designing APL systems that are Searching, Part 4 Tl Ray Jordan, editor of APL Mar­ user friendly, maintainable, and Joint Representation T3 ket News, in his talk estimated efficient. These talks organized key New System Variable, there are over 100 000 persons concepts in the design of APL sys­ □EC TS who know some APL. Also the tems. Starting with a fundamental Workspace of the number of APL vendors has design and implementation philoso­ Month: 7 WSSEARCH T7 grown, from 10 in the late '60s phy, they go on to give you Drawing APL Trees: and early '70s, to 140 in 1982.
    [Show full text]
  • The Common Locale Repository - Update
    The Common Locale Repository - Update Dr. Mark Davis Steven R. Loomis [email protected] [email protected] Copyright © 2004 IBM Corporation 1. Introduction Unicode has provided a foundation for communicating textual data. However, the locale- dependant data used to drive features such as collation and date/time formatting may be incorrect or inconsistent between systems. This may not only present an irritating user experience, but prevent accurate data transfer. The Common XML Locale Repository is a step towards solving these problems, by providing an interchange format for locale data and developing a repository of such data available. In this document, a “Locale” is an identifier that refers to a set of linguistic and cultural preferences. Traditionally, the data associated with such a locale provides support for formatting and parsing of dates, times, numbers, and currencies; for the default units of currency; for measurement units, for collation (sorting), plus translated names for time zones, languages, countries, and scripts. They can also include text boundaries (character, word, line, and sentence), text transformations (including transliterations), and support for other services. Because locale data changes over time, the data must be versioned to provide stability. Examples of platforms with their own locale data are ICU1, OpenOffice.org, and POSIX and POSIX-like operating systems such as Linux, Solaris, and AIX. 2. Common XML Locale Repository Group OpenI18N2, formerly known as "Li18nux", is a workgroup of the Free Standards
    [Show full text]
  • Ansi Mh10.8.2-2016"
    This is a preview of "ANSI MH10.8.2-2016". Click here to purchase the full version from the ANSI store. ANSI MH10.8.2-2016 American National Standard Data Identifier and Application Identifier Standard Approved: June 10, 2016 Abstract This standard provides a comprehensive dictionary of MH 10/SC 8 Data Identifiers and GS1 Application Identifiers, provides for the assignment of new Data Identifiers, as required, and provides a document detailing the correlation, or mapping, of Data Identifiers to Application Identifiers, where a correlation exists. Material Handling Industry 8720 Red Oak Blvd., Suite 201 Charlotte, NC 28217-3992 Published: v20160108 i This is a preview of "ANSI MH10.8.2-2016". Click here to purchase the full version from the ANSI store. Approval of an American National Standard requires verification by the American American National Standards Institute (ANSI) that the requirements for due process, consensus, and other criteria for approval have been met by the standards National developer. Consensus is established when, in the judgment of the ANSI Board of Standards Standard Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effort be made toward their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard.
    [Show full text]
  • Sc22/Wg20 N860
    Final Draft for CEN CWA: European Culturally Specific ICT Requirements 1 2000-10-31 SC22/WG20 N860 Draft CWA/ESR:2000 Cover page to be supplied. Final Draft for CEN CWA: European Culturally Specific ICT Requirements 2 2000-10-31 Table of Contents DRAFT CWA/ESR:2000 1 TABLE OF CONTENTS 2 FOREWORD 3 INTRODUCTION 4 1 SCOPE 5 2 REFERENCES 6 3 DEFINITIONS AND ABBREVIATIONS 6 4 GENERAL 7 5 ELEMENTS FOR THE CHECKLIST 8 5.1 Sub-areas 8 5.2 Characters 8 5.3 Use of special characters 10 5.4 Numbers, monetary amounts, letter written figures 11 5.5 Date and time 12 5.6 Telephone numbers and addresses, bank account numbers and personal identification 13 5.7 Units of measures 14 5.8 Mathematical symbols 14 5.9 Icons and symbols, meaning of colours 15 5.10 Man-machine interface and Culture related political and legal requirements 15 ANNEX A (NORMATIVE) 16 Final Draft for CEN CWA: European Culturally Specific ICT Requirements 3 2000-10-31 FOREWORD The production of this document which describes European culturally specific requirements on information and communications technologies was agreed by the CEN/ISSS Workshop European Culturally Specific ICT Requirements (WS-ESR) in the Workshop’s Kick-Off meeting on 1998-11-23. The document has been developed through the collaboration of a number of contributing partners in WS-ESR. WS- ESR representation gathers a wide mix of interests, coming from academia, public administrations, IT-suppliers, and other interested experts. The present CWA (CEN Workshop Agreement) has received the support of representatives of each of these sectors.
    [Show full text]
  • Database Globalization Support Guide
    Oracle® Database Database Globalization Support Guide 19c E96349-05 May 2021 Oracle Database Database Globalization Support Guide, 19c E96349-05 Copyright © 2007, 2021, Oracle and/or its affiliates. Primary Author: Rajesh Bhatiya Contributors: Dan Chiba, Winson Chu, Claire Ho, Gary Hua, Simon Law, Geoff Lee, Peter Linsley, Qianrong Ma, Keni Matsuda, Meghna Mehta, Valarie Moore, Cathy Shea, Shige Takeda, Linus Tanaka, Makoto Tozawa, Barry Trute, Ying Wu, Peter Wallack, Chao Wang, Huaqing Wang, Sergiusz Wolicki, Simon Wong, Michael Yau, Jianping Yang, Qin Yu, Tim Yu, Weiran Zhang, Yan Zhu This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S.
    [Show full text]
  • ANSI MH10.8.2 CM2020-08-27+.Pdf
    ANS MH10.8.2-2016 (Continuous Maintenance of ANS MH10.8.2-2016) American National Standard Data Identifier and Application Identifier Standard Approved: June 10, 2016 Updated: August 27, 2020 Abstract This standard provides a comprehensive dictionary of MH 10/SC 8 Data Identifiers and GS1 Application Identifiers, provides for the assignment of new Data Identifiers, as required, and provides a document detailing the correlation, or mapping, of Data Identifiers to Application Identifiers, where a correlation exists. Material Handling Industry 8720 Red Oak Blvd., Suite 201 Charlotte, NC 28217-3992 Published: v20120621 Approval of an American National Standard requires verification by the American American National Standards Institute (ANSI) that the requirements for due process, consensus, and other criteria for approval have been met by the standards National developer. Consensus is established when, in the judgment of the ANSI Board of Standards Standard Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effort be made toward their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in the name of the American National Standards Institute.
    [Show full text]
  • A Method for Reusing and Re-Engineering Non-Ontological Resources for Building Ontologies
    Departamento de Inteligencia Artificial Facultad de Informatica´ PhD Thesis A Method for Reusing and Re-engineering Non-ontological Resources for Building Ontologies Author : Msc. Boris Marcelo Villazon´ Terrazas Advisor : Prof. Dr. Asuncion´ Gomez´ Perez´ 2011 ii Tribunal nombrado por el Sr. Rector Magfco. de la Universidad Politecnica´ de Madrid, el d´ıa...............de.............................de 20.... Presidente : Vocal : Vocal : Vocal : Secretario : Suplente : Suplente : Realizado el acto de defensa y lectura de la Tesis el d´ıa..........de......................de 20...... en la E.T.S.I. /Facultad...................................................... Calificacion´ .................................................................................. EL PRESIDENTE LOS VOCALES EL SECRETARIO iii iv Abstract Current well-known methodologies for building ontologies do not consider the reuse and possible subsequent re-engineering of existing knowledge resources. The ontologization of non-ontological resources has led to the design of several specific methods, techniques and tools. These are mainly specific to a particular resource type, or to a particular resource implementation. Thus, everytime ontol- ogy engineers are confronted with the task of re-engineering a new resource into an ontology, they develop ad-hoc solutions for transforming such resource into a single ontology. Within the context of the NeOn project, we propose a novel methodology for building ontology networks: the NeOn Methodology, a methodology based on sce- narios. One
    [Show full text]
  • Semantics of Business Vocabulary and Business Rules (SBVR)
    Date: May 2015 OBJECT MANAGEMENT GROUP Semantics of Business Vocabulary and Business Rules (SBVR) Version 1.3 OMG Document Number: formal/2015-05-07 Standard document URL: http://www.omg.org/spec/SBVR/1.3/PDF Normative Machine Consumable Files: http://www.omg.org/spec/SBVR/20141201 http://www.omg.org/spec/SBVR/20141201/SBVR-model.xml http://www.omg.org/spec/SBVR/20141201/SBVR.xsd http://www.omg.org/spec/SBVR/20141201/SBVR.xml Copyright © 2005-2007, Business Rule Solutions, LLC Copyright © 2005-2007, Business Semantics Ltd Copyright © 2005-2007, Fujitsu Ltd Copyright © 2005-2007, Hendryx & Associates Copyright © 2005-2007, LibRT Copyright © 2005-2007, KnowGravity Inc Copyright © 2005-2007, Model Systems Copyright © 2005-2007, Neumont University Copyright © 1997-2015, Object Management Group Copyright © 2005-2007, Unisys Corporation USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company’s products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification.
    [Show full text]
  • International Standard Iso/Iec 26300-2
    This is a previewINTERNATIONAL - click here to buy the full publication ISO/IEC STANDARD 26300-2 First edition 2015-07-01 Information technology — Open Document Format for Office Applications (OpenDocument) v1.2 — Part 2: Recalculated Formula (OpenFormula) Format Technologies de l’information — Format de document ouvert pour applications de bureau (OpenDocument) v1.2 — Partie 2: Titre manque Reference number ISO/IEC 26300-2:2015(E) © ISO/IEC 2015 ISO/IEC 26300-2:2015(E) This is a preview - click here to buy the full publication COPYRIGHT PROTECTED DOCUMENT © ISO/IEC 2015 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form orthe by requester. any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of Case postale 56 • CH-1211 Geneva 20 ISOTel. copyright+ 41 22 749 office 01 11 Fax + 41 22 749 09 47 Web www.iso.org E-mail [email protected] Published in Switzerland ii © ISO/IEC 2015 – All rights reserved This is a preview - click here to buy the full publication ISO/IEC 26300-2:2015(E) Open Document Format for Office Applications (OpenDocument) Version 1.2 Part 2: Recalculated Formula (OpenFormula) Format OASIS Standard 29 September 2011 Specification URIs: This version: http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.odt (Authoritative) http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.pdf
    [Show full text]
  • ISO 4217:2015 F6420818cd81/Iso-4217-2015
    INTERNATIONAL ISO STANDARD 4217 Eighth edition 2015-08-01 Codes for the representation of currencies Codes pour la représentation des monnaies iTeh STANDARD PREVIEW (standards.iteh.ai) ISO 4217:2015 https://standards.iteh.ai/catalog/standards/sist/883c2db4-4cca-4664-8865- f6420818cd81/iso-4217-2015 Reference number ISO 4217:2015(E) © ISO 2015 ISO 4217:2015(E) iTeh STANDARD PREVIEW (standards.iteh.ai) ISO 4217:2015 https://standards.iteh.ai/catalog/standards/sist/883c2db4-4cca-4664-8865- f6420818cd81/iso-4217-2015 COPYRIGHT PROTECTED DOCUMENT © ISO 2015, Published in Switzerland All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form orthe by requester. any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of Ch. de Blandonnet 8 • CP 401 ISOCH-1214 copyright Vernier, office Geneva, Switzerland Tel. +41 22 749 01 11 Fax +41 22 749 09 47 www.iso.org [email protected] ii © ISO 2015 – All rights reserved ISO 4217:2015(E) Contents Page Foreword ........................................................................................................................................................................................................................................iv Introduction ..................................................................................................................................................................................................................................v
    [Show full text]
  • XBRL Formula Requirements
    XBRL INTERNATIONAL PUBLIC WORKING DRAFT XBRL Formula Requirements Public Working DRAFT of Tuesday, 20 April 2004 This file: Formula-Req-PWD-2004-04-20.doc Updates the public working draft originally posted at: http://www.xbrl.org/tr/2002/XBRL-Rule-Base-Req-WD-2002-11-16.doc Editors Name Contact Affiliation Walter Hamscher1 [email protected] Standard Advantage Contributors Geoff Shuetrim [email protected] KPMG LLP David vun Kannon [email protected] KPMG LLP Status of this document This is a public working draft whose circulation is unrestricted. It may change and is not appropriate to reference from public documents. Comments should be directed to the editor and/or contributors by e-mail. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. Table of contents Editors.......................................................................................................................1 Contributors ...............................................................................................................1 Status of this document ...............................................................................................1 Table of contents.........................................................................................................1 1 Motivation (non-normative) ...................................................................................2 2 Use cases ...........................................................................................................4
    [Show full text]
  • Interim Report #2 on the Euro in IT Standardization
    N853 1998-10-12 CEN/TC 304 N853 Title: Interim Report #2 on the Euro in IT Standardization Source: Erkki Kolehmainen, CEN/TC304 Euro Project Team leader Date: 10 Oct 1998 Status: A draft presented by Wolf Arfvidson at SOGITS meeting in October, replaces N838 Action: FYI Interim Report #2 on the Euro in IT Standardization This is a cumulative report. In this version, vendor-specific information is given for illustrative purposes only. The next version of this Report (which is intended to be the final one) is due by the end of December. In this version, substantial changes to the previous version are indicated by change bars (see here on the right). 1. Euro Currency Codes, Logo and Glyph The Currency Code for the Euro for use in monetary transfers by financial institutions et al. has been registered in the three-letter form as ‘EUR’ and in the numeric form as ‘978’ with the international registration authority BSI (British Standards Institute) appointed by ISO according to standard ISO 4217. Note: This three-letter code does not follow the normal rule: the two-letter country code (‘EU’, not registerable as such although reserved) followed by the first letter in the name of the currency (which normally would be ‘E’). The Euro sign has evolved from the initial logo to also a new character. The logo is defined as a rounded E with double line for the central horizontal bar, blue with yellow background (ref: COM(97) 418fin). The logo may be downloaded from website http://europa.eu.int/euro/ . As a character, the shape of the Euro sign needs to adapt to the textual environment.
    [Show full text]