Abstract
APL is often presented as a notation that is independent of national language because of its symbolic nature. Paradoxically its unique character set has led to APL being treated as if it were itself a national language. This has meant, in many practical situations, that the APL character set is incompatible with national language character sets. IBM's APL2 attempted to avoid these problems by defining a set of extended (31 bit) characters, and this has indeed been helpful in handling Asian languages such as Kanji. But the character mappings adopted have not been adequate to support all European and Middle Eastern language characters, nor have they been consistent across platforms. With the advent of international standards for character assignment, there is an opportunity to create APL systems that handle the character sets of the world in an efficient and elegant manner. While at first the solution appears to require only a recitation of code point assignments, an analysis of the problem leads to interesting and disturbing questions about a number of APL system functions, system variables, commands, and file facilities. This paper explores problems with internal conversions, external representations, migration, compatibility, and interplatform portability.