@@ -11,7 +11,7 @@ To make the process as smooth as possible, this document outlines all the things
1111- [Stricter Record Update Syntax](#stricter-record-update-syntax)
1212- [Removed User-Defined Operators](#removed-user-defined-operators)
1313
14−> **Note:** You can try out [`elm-upgrade`](https://github.com/avh4/elm-upgrade/tree/rc#elm-upgrade--) which automates some of the 0.18 to 0.19 changes. It is also in an alpha stage, and Aaron has said it makes sense to talk things through [here](https://github.com/avh4/elm-upgrade/issues).
14+> **Note:** You can try out [`elm-upgrade`](https://github.com/avh4/elm-upgrade#elm-upgrade--) which automates some of the 0.18 to 0.19 changes. It is also in an alpha stage, and Aaron has said it makes sense to talk things through [here](https://github.com/avh4/elm-upgrade/issues).
1515
1616<br>
1717
@@ -159,4 +159,4 @@ They are still able to define that function, but it will need a human readable n
159159
160160## Notes:
161161
162−- `toString` — A relatively common bug was to show an `Int` in the UI, and then later that value changes to something else. `toString` would just show wrong information until someone noticed. The new `String.fromInt` and `String.fromFloat` ensure that cannot happen. Furthermore, more elaborate types almost certainly need localization or internationalization, which should be handled differently anyway.
162+- `toString` — A relatively common bug was to show an `Int` in the UI, and then later that value changes to something else. `toString` would just show wrong information until someone noticed. The new `String.fromInt` and `String.fromFloat` ensure that cannot happen. Furthermore, more elaborate types almost certainly need localization or internationalization, which should be handled differently anyway.