Hello,

I have prepared Russian translation for TOML (#700). I got several ambiguation. Here are my notes, which I think should be corrected.

Notes which request a better explanations / example:

• 1. In Spec there are defined Whitespace and Newline, but in the multi line Strings uses term "Whitespace characters", which includes both terms.
• 6. In the data-time sections a lot of duplications which could be express in better way (I suppose) (related PR Make seconds optional in times #696)
• 7. Some ambiguation: you text that "A TOML file must be a valid UTF-8 encoded Unicode document",
  but class Whitespace characters is defined very poor. What if there are
  other UTF-8 whitespace characters before a Key?

Work-in-Progress:

• 3. Some paragraphs contains more than one idea, and it is better to split them into several to improve readability. For example, when multi-line Strings are defined at the same time there is enumeration of its properties, which may be separated and have dedicated link anchor. (WIP [WIP] Split paragraphs, make definition of Integer as Float #705)
• 5. In Integer definition as I suppose, it says "64 bit (signed long) range expected ...", but it is not clear defined that implementation should use signed long encoding. (WIP [WIP] Split paragraphs, make definition of Integer as Float #705, alse there is discussion in Integer type specification question #688)

Closed notes:

• 2. It is useful to use more heading levels with #, ##, ### and etc, It makes table of content more structured and easy to refer to exact part if it require. (Note: also it would be useful to pdf rendering with pandoc as Example) (this topic are touched in Explain nested nature of dotted key notation #702, and moved to Reorganization of TOML specification #703 and Re-organization of sections in TOML documentation/specification  #704 )
• 4. Table should be renamed to Hash Table or Dictionary. This word makes wrong association with CSV and Spreadsheets (Which I initially expected). (With context "Table" as name is OK. comment)
• 5.1 You try to define (or recommend) hardware limitations of numbers (like 64 bit or IEEE binary64. But as mentions a lot of times it is really hardware specific. Maybe you should describe more clear a template of relationships between toml and hardware, and provide "recommended" filled template which appropriate for the most cases (i.e. x64). (Discussion in Define appropriate implementation behaviors for extreme values #538)
• 8. Do you have any recommendations to keep TOML document compatible with INI format, or Shell file (with variables only)? It would be good practice to prepare system to transfer from INI to TOML format. (Clearly described in comment)
• 9. This example really unexpected (from README.md) (WIP: Explain nested nature of dotted key notation #702, now it is Clarify example showing how to add new keys #706):

# As I understand It is valid
fruit.apple.smooth = true
fruit.orange = 2

# THIS IS INVALID (why not?)
fruit.apple = 1
fruit.apple.smooth = true

• 10. I suggest also define .tml extension, I program embedded device with FAT32
  and I limited with DOS 8.3 filename format. So I have to make it simple .txt (which is more desirable in my case, actually). (discussed in rename toml => tml #573)