-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use an atom instead of a var for text dictionary. #41
Conversation
did you tied it to see if it works with a game (perhaps the example-game)? I worry about some translated strings that are used in maps and things like that, I remember at some point I had issues with setting the dictionary after the advenjure namespaces were initialized |
I'll try on mine. I'll add some tests if you want using your different tense dictionaries. |
Tests are not necessary I think, just want to make sure it works before merging |
I tried both on jvm and javascript. Phrases I changed were indeed replaced in both cases. |
the |
I made a fork of the example game and set a branch dictionary-test where I set the dictionary to the present tense one. It works as expected on my manual checks. You can clone my advenjure repo, install it to your local maven repo then clone the advenjure-example one to test it by yourself. |
Oh. I got a case where it does not work as expected. The en_present dictionary does not cover the article case for "a" and "an" that the en_past dictionary covers. I think it's more an oversight in the en_present dictionary than anything else. |
I just tested using the spanish translations, and this suffers the case I mentioned earlier. The english present that you tested is ok because it doens't redefine the verbs, but in spanish this happens:
The reason is that the verbs are defined statically in the code so by the time the atom is assigned they are already defined using the default language. (here for example) The original gettext read the dictionary from a configuration file so it worked statically; we'll need to think this one a bit more to make it work. I think for the purposes of your game you'll be better off by forking and changing the default dictionary to point to the namespace with your translations. |
Another option to explore is to use closure-defines to point a translation dictionary in project.clj That would work for clojurescript (which is the priority), and maybe we could bring back carica for clojure. |
Oh I see ! indeed verbs are statically constructed.
Isn't there an issue on how the dictionary is defined and how your gettext function work ? But If I look at the gettext function I see there is no mecanism to match that regex. So when a call to
Here I see two way of doing it:
|
I just wrote two commits to my branch. The first one explore the dynamically construct verbs and verb-map. The second rewrite the espagnol dictionary for matching the way you refer to text in the verbs file. Es verbs are indeed available. The dictionary isn't full yet, and some verbs aren't dynamically defined either (tike take). I'll fix that this afternoon. Edit : there is not just verbs that are statically constructed, but directions too. Directions are a little more deeply coupled with the rest of the code. I'll put that on my stack too but I think it needs more reflexion. |
OK. After some reflexion I just hit the conclusion that using static dictionary would be far more easier. (Sorry for experimenting, you have a far larger overview of your project than I do) I just saw your original gettext library and I think it's pretty neat and that we should make it work for clojurescript. I guess the missing point was carica not portable to clojurescript ? I suggest we use cprop that is a both java / javascript configuration reader. EDIT : I'm wrong, cprop isn't clojurescript compliant. Searching for something working… |
Okay, was wondering how people are doing to compile clojurescript code using configurations maps. The trick is to bind the configuration at compile time using macro and it work as is in clojurescript. An exemple is given in this discussion. If we just wrap your carica calls in a macro I think gettext should be portable as is. |
Did you see my comment above about closure-defines? I think that should be enough for clojurescript. |
Yes it's working too. I just supposed you would like having your previous workflow working. I made another fork here where I show how it could be done. This solution works for both clojure and clojurescript and should be use in gettext. The key is to load the dictionary during macro expand time. |
Nice, that looks good. You can make A PR with that change and let me test it over the weekend. |
closing this in favor of #43 |
Purpose : modification of the text source dictionary is easier with an atom and works both in Clojure and Clojurescript. It can change default text used internally.
The change is pretty light.
I also add a
set-dictionary!
function for providing a clear way of changing the dictionary. So if you want to swap atom for another construct it will be transparent for the API user.