Hi JCM,
Welcome to the list.
I want to answer the internationalization question first, because I think it might be of interest to several others on the list. (Just in case anybody else is in my ignorance league, "i18n" is short for
internationalization. The 18 in the middle stands for the 18 letters between the i and the n.)
There are several things we need to do before W2n is effectively i15d (internationalized):
- handle unicode characters properly. This would not take much effort, and we would pounce on the opportunity to do this with even minimal funding.
- internationalize our "keys". This depends on the unicode fix, but also means either making it possible to opt out of our English-biased pluralization handling or finding a way to make it more language-flexible
- continue moving English content embedded in the software out into cards, so that all the inline instructions can be translated.
With these changes, I suspect Wagn would be quite ready for most languages. Folks on this list may or may not know that we've started moving a lot
of our language development out of code and into a into an "English" wagn that we use for our default deploys. With this structure it will be trivial to add many other language wagns so our community can help us evolve default wagns for any language.
But the question was about
translation, which can be a bit more involved. Few wikis have much direct support for translation, and instead they either just use unique names for different language versions of different pages or, like Wikipedia, they put the different languages on entirely separate wikis. You could certainly do either of these in Wagn.
A more advanced solution involves actually mapping different translations of the same page, so that if your language is present you get to see that version and if not you see another one. I think Tikiwiki may have something like that. Wagn does not yet, but it would be great to build it.
It would be particularly fascinating to see how this might dovetail with wagn's structuring, which could ultimately support a highly advanced and nuanced solution, but might complicate the development process.
CardtypesAs for your other question, in general it's very easy to add custom cardtypes. You can do simple ones through the interface, and via code you can certainly add new models and interfaces. We haven't invested a lot of time in documenting how to do this yet because we're expecting to revamp our modularization / plugin system shortly after 1.0 and we don't want to have to support too many legacy plugin cardtypes, but the structure is in place and it's only going to get better and more powerful.
- ethan
--
Ethan McCutchen
Executive Director, Grass Commons
GrassCommons.org, Wagn.org
skype: ethan.mccutchen
freenode: #grasscommons, #wagn
cell:
(541) 521-0422
mean what you pay