Updated LCD Language (markdown)

LCD-Language.md

@@ -93,8 +93,8 @@ On a 'perfect' system like Windows or Linux we'd dig out `unifont.ttf` and some
 - Make three fonts to simulate the HD44780 charsets on dogm-displays. With this fonts the translator can check how his translation will look on the character based displays.
 - Make ISO fonts for Cyrillic and Katakana because they do not need a mapping table and are faster to deal with and have a better charset (less compromises) than the HD44780 fonts.
 - Make mapping functions and tables to convert from UTF8 to the fonts and integrate in the new output functions. (`utf_mapper.h`)
-- Delete the obsolete `LiquidCrystalRus.xxx` files and their calls in 'ultralcd_implementation_hitachi_HD44780.h'.
-- Split 'dogm_font_data_Marlin.h' into separate fonts and delete. (+`dogm_font_data_6x9_marlin.h`, +`dogm_font_data_Marlin_symbols.h`, -`dogm_font_data_Marlin.h`)
+- Delete the obsolete `LiquidCrystalRus.xxx` files and their calls in '`ultralcd_implementation_hitachi_HD44780.h`'.
+- Split '`dogm_font_data_Marlin.h`' into separate fonts and delete. (+`dogm_font_data_6x9_marlin.h`, +`dogm_font_data_Marlin_symbols.h`, -`dogm_font_data_Marlin.h`)
 - Do a bit of preprocessor magic to match displays - fonts and mappers in `utf_mapper.h`.
 
 ## Translators handbook
@@ -126,16 +126,16 @@ If you get a lot of question marks on the Hitachi-based displays with your new t
 - `MAPPER_NON` is the fastest and least memory-hungry variant.
 - Mappers together with a ISO10646_font are the second-best choice regarding speed and memory consumption. Only a few more decisions are made per-character.
 - Mappers together with the HD44780_fonts use about additional 128 bytes for the mapping_table.
-- Creating a new language file is not a big thing. Just make a new file with the format 'language_xx.h' or maybe 'language.xx.utf8.h', define a mapper and a font in there and translate some of the strings defined in language_en.h. You can drop the surrounding  #ifndef #endif. You don't have to translate all the stings - the missing one will be added by language_en.h - in English - of cause.
-- If you can't find a matching mapper things will be a bit more complex. With the Hitachi-based displays you won't have big chance to make something useful unless you have one with a matching charset. For a full graphic display - lets take the example of Greek:
+- Creating a new language file is not a big thing. Just make a new file with the format '`language_xx.h`' or maybe '`language.xx.utf8.h`', define a mapper and a font in there and translate some of the strings defined in `language_en.h`. You can drop the surrounding `#ifndef` `#endif`. You don't have to translate all the strings - the missing one will be added by `language_en.h` - in English - of course.
+- If you can't find a matching mapper things will be a bit more complex. With the Hitachi-based displays you won't have be able to make something useful unless you have one with a matching charset. For a full graphic display - lets take the example of Greek:
   - Find a matching charset. ([Greek and Coptic](http://en.wikipedia.org/wiki/Greek_and_Coptic))
   - Provide a font containing the symbols in the right size. Normal ASCII in the lower 127 places, the upper with your selection.
-  - Write a mapper that catches -in this case- 0xCD to 0xCF and add it to `utf_mapper.h`.
+  - Write a mapper that catches -in this case- `0xCD` to `0xCF` and add it to `utf_mapper.h`.
   - In case of a ISO10646 font we have a `MAPPER_ONE_TO_ONE` and don't have to make a table.
   - If you discover enough useful symbols in one of the HD44780 fonts you can provide a mapping table. For example `WESTERN` contains 'alpha', 'beta', 'pi', 'Sigma', 'omega' 'My' - which is not enough to make USEFUL table - I think.
-  -  If you want to integrate an entirely new variant of a Hitachi based display. Add it to `Configuration.h`. Define mapper tables in `utf_mapper.h`. Maybe you need a new mapper function.
+  - If you want to integrate an entirely new variant of a Hitachi-based display. Add it to `Configuration.h` and define mapper tables in `utf_mapper.h`. You may need to add a new mapper function.
 
-The length of the strings is limited. '17 chararacters' was a crude rule of thumb. Obviously 17 is too long for the 16x2 displays. A more exact rule would be `max_strlen = Displaywidth - 2 - strlen(value to display behind)`. This is a bit complicated. So try and count is my rule of thumb.
+The length of the strings is limited. "17 chararacters" was a crude rule of thumb. Obviously 17 is too long for the 16x2 displays. A more exact rule would be `max_strlen = LCD_WIDTH - 2 - strlen(edit_value)`. This is a bit complicated. So try and count is my rule of thumb.
 
 On the 16x2 displays the strings are cut at the end to fit on the display. So it's a good idea to make them differ early. ('`Someverylongoptionname x`' -> '`x Somverylongoptionname`')
 
@@ -149,9 +149,9 @@ Define your hardware and the desired language in `Configuration.h`.
 
 To find out what character set your hardware uses, set `#define LCD_LANGUAGE test` and compile Marlin. In the menu you'll see two lines from the upper half of the character set:
 
-- `JAPANESE` displays "バパヒビピフブプヘベペホボポマミ"
-- `WESTERN` displays "ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß"
-- `CYRILLIC` displays "РСТУФХЦЧШЩЪЫЬЭЮЯ"
+- `JAPANESE` displays "`バパヒビピフブプヘベペホボポマミ`"
+- `WESTERN` displays "`ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß`"
+- `CYRILLIC` displays "`РСТУФХЦЧШЩЪЫЬЭЮЯ`"
 
 If you get an error message about "missing mappers" during compilation - lie about your display's hardware font to see at least some garbage, or select another language.