On 2019-03-27, Jürgen Spitzmüller wrote: > Am Mi., 27. März 2019 um 17:54 Uhr schrieb Günter Milde <[email protected]>:
>> commit 4a2f4fb1d63ae6d7cd96012c375753aa146a815b >> Author: Günter Milde <[email protected]> >> Use LaTeX input encoding "utf8", part 1/many. >> See #11115. > As argued on trac, I think we should stick with \inputencoding auto and > change languages instead. Changing the default input encodings in "lib/languages" creates a backwards-incompatibility that cannot be solved for some documents. A lyx2lyx conversion (as outlined in https://www.lyx.org/trac/ticket/11115#comment:16) will break documents with text parts in Japanese, Chinese, Korean, Arab, or Farsi and "\inputencoding auto", because a) the setting "\inputencoding auto" has two components: * use the encoding as specified in "lib/languages" as main encoding * switch the input encoding for text parts in different languages, b) these languages are only supported with a "native" fixed-8-bit encoding or utf8. OTOH, setting "\inputencoding utf8" in templates and examples: + Requires no file format change. No backwards compatibility problems. Existing documents are exported as before. + Does not add restrictions to mixing languages in a document. "utf8" works for all languages except "Japanese (platex)". However, "Japanese (platex)" cannot be used as secondary language anyway. Users still have the chance to use Japanese, Chinese, Korean, Arab, or Farsi in documents with fixed 8-bit legacy encodings for the main text. + Allows a step-wise change with proper testing. Users with a custom standard template (defaults.lyx) will have to change this manually in any case: "defaults.lyx" is converted with lyx2lyx before beeing used for new documents. With the proposed conversion functions, "inputenc auto" will be replaced with the document language's previous 8-bit default encoding. What are the benefits of changing default encodings in lib/languages over changing "\inputencoding" in templates and examples? Günter
