There's been significant efforts to "translate" or more precisely "adapt" significant parts of the standard with good presentations in Wikipedia and various sites for scoped topics. So there are alternate charts, and instead of translating all, the concepts are summarized, reexplained, but still give links to the original version in English everytime more info is needed. All UCD files don't need to be translated, they can also be automatically processed to generate alternate presentations or datatables in other formats. There's no value in taking efforts to translate them manually, it's better to develop a tool that will process them in the format users can read.
So remove the UCD files and the tables from the count, as well as sample code (which is jsut demontrative and uses simplified non optimal implementation to keep this code clear). We an now have separate tools or websites presenting them and proposing commented code which is also better performing. We have large collections of i18n libraries that were developed for various development platforms and usage documentation in various languages. The only efforts is in: * naming characters (Wikipedia is great to distribute the effort and have articles showing relevant collections of characters and document alternate names or disambiguate synonyms). * the core text of the standard (section 3 about conformance and requirements is the first thing to adapt). There's absolutely no need however to do that as a pure translation, it can be rewritten and presented with the goals wanted by users. Here again Wikiepdia has done significant efforts there, in various languages * keeping the tools developed in the previous paragraph in sync and conformity with the standard (sync the UCD files they use). 2018-03-05 19:21 GMT+01:00 Ken Whistler via Unicode <firstname.lastname@example.org>: > > On 3/5/2018 9:03 AM, suzuki toshiya via Unicode wrote: > > I have a question; if some people try to make a > translated version of Unicode > > > And to add to Asmus' response, folks on the list should understand that > even with the best of effort, the concept of a "translated version of > Unicode" is a near impossibility. In fairly recent times, two serious > efforts to translate *just *the core specification -- one in Japanese, > and a somewhat later attempt for Chinese -- crashed and burned, for a > variety of reasons. The core specification is huge, contains a lot of very > specific technical terminology that is difficult to translate, along with a > large collection of script- and language-specific detail, also hard to > translate. Worse, it keeps changing, with updates now coming out once every > year. Some large parts are stable, but it is impossible to predict what > sections might be impacted by the next year's encoding decisions. > > That is not including that fact that "the Unicode Standard" now also > includes 14 separate HTML (or XHTML) annexes, all of which are also moving > targets, along with the UCD data files, which often contain important > information in their headers that would also require translation. And then, > of course, there are the 2000+ pages of the formatted code charts, which > require highly specific and very complicated custom tooling and font usage > to produce. > > It would require a dedicated (and expensive) small army of translators, > terminologists, editors, programmers, font designers, and project managers > to replicate all of this into another language publication -- and then they > would have to do it again the next year, and again the next year, in > perpetuity. Basically, given the current situation, it would be a fool's > errand, more likely to introduce errors and inconsistencies than to help > anybody with actual implementation. > > People who want accessibility to the Unicode Standard in other languages > need to scale down their expectations considerably, and focus on preparing > reasonably short and succinct introductions to the terminology and > complexity involved in the full standard. Such projects are feasible. But a > full translation of "the Unicode Standard" simply is not. > > --Ken >