| Age | Commit message (Collapse) | Author |
|---|
|
Check that translation and the `ReaderT` really do work by changing
localisation of the STDOUT "help" output from `EN` to `FR`.
To actually test this, add a french translation of the `GitHubCommit`
plugin description. This string is successfully output by the "help"
plugin.
|
|
This is an attempt at wrapping the functions in this plugin with the new
`Bot` monad. It didn't go very well.
These changes are the result of some initial code and then a lot of
fiddling to try to resolve compiler errors, many of which are still
present.
The ultimate goal is to be able to wrap the functions in `Bot` so that
we can use the language configuration option to determine which
translation to use.
Thanks to 'dmwit' on Freenode#haskell for looking at my code and giving
me suggestions for my type errors.
|
|
Get the language from the command line options and use it to determine
which localised string to return on error. Wooo!! it works! So cool.
Add French translations for our existing strings.
The code to get the language option is pretty messy for the moment. I
want to factor it out into its own separate function. But at least it's
working now.
|
|
Instead of parsing `--language` as a string, parse it as a real `Locale`
type. This means the parsing is taken care of for us at the CLI option
handling stage instead of later on.
We can thus use the language value more quickly and easily, passing it
to the `translate` function, which takes a `Locale`.
|
|
Follow the example
https://wiki.haskell.org/Internationalization_of_Haskell_programs_using_Haskell_data_types
to get i18n.
Get rid of the Shakespeare-I18N code. The idea of using text files to
define translation strings was nice, but since I couldn't get it working
with ease and couldn't find examples outside of a Yesod context, I
decided to chuck it and go with the alternative, simpler approach.
Really liking this system. Simplified things a bit from the example
since we only need to show one language at a time. Will need to figure
out how to use the same language throughout the program.
|
|
An unsuccessful attempt at getting i18n working through Shakespeare. Had
a little help from:
https://gist.github.com/nicolashery/f87467fb37da2b00cec1eed028f51e60
Unfortunately, I can't figure out how to get this working. Even before,
without the locale stuff and defining a custom `translate` function,
when I tried using Shakespeare's `_{}` function, I was, and still am,
getting this error:
src/Plugin/GitHubCommit.hs:38:29: error:
Data constructor not in scope: MsgGitHubCommitRepoURLNotFound
Yes, obviously, that makes sense. But how do I get it to be in scope if
it isn't even in my code? What?
I'm giving up on Shakespeare for i18n. It was a nice idea, I liked the
fact that strings were stored in external files, but I don't know how to
do this, I can't find the right resources online to use this in a
non-web non-template context, and it's becoming a pain. Going to get rid
of all this code and just use regular Haskell data types to do it as
described in
https://wiki.haskell.org/Internationalization_of_Haskell_programs
|
|
en.msg:
* Remove comment lines because apparently comments aren't allowed by the
parser
* Change data type to `T.Text` to match the import from the `I18n`
module
GitHubCommit.hs:
Import the `I18n` module because we'll be testing it in context in a
bit, but for now just want to get the module code to compile.
I18n.hs:
Follow the example on http://www.yesodweb.com/book/internationalization
to make a function for proper internationalisation.
|
