Re: [Monotone-devel] second go at i18n spec

[Christof Petig]

The proposal looks good to me. But we need binary (do never try to 
convert encoding) flags for files. Reason below.

Mixing encodings within a project might not be that uncommon (e.g. 
managing xml files in different encodings)

   Christof

graydon hoare schrieb:
>   - filenames are subject to an additional normal form stage which
>     adjusts for platform name semantics, for example changing the
>     Windows 0x5C '\' path separator to 0x2F '/' and changing the root
>     designator from "C:\" to "/". this extra processing is performed
>     by boost::filesystem.

Original idea:
----->8-------
If it would be not too much hassle the possibility to specify a 
different encoding for filenames than for file content would save me 
much trouble. [e.g. my toolkit uses UTF-8 for strings and my shell still 
likes ISO or vice versa.*)] But then the encoding for a Makefile might 
differ from a program source file => encoding per file? *2)
----->8-------

Perhaps this is overengeneering. I can live with UTF-8 filenames in 
UTF-8 projects. But ... If I use UTF-8 filenames (encoding) I cannot 
check in ISO files (unless marked binary) because they form invalid 
UTF-8 codes.

This seems strange and it is debatable whether the VCS should force you 
to use a sane non-mixture of encodings or whether the VCS just should 
stay out of your way [which it can't if it tries to store everything in 
UTF-8].

*) This is not uncommon because e.g. gtk1 and gtk2 use different 
encodings in Germany.

*2) marking the source (and xml files, which specify their own encoding) 
as binary (never try to use a different encoding) and the Makefile as 
text would solve this problems.