till now, games::risk was using map files from jrisk. this allowed me to concentrate on the gui and the game experience without having to tackle everything at once.
being a simple format, it was somehow easy to read the maps... but its simplicity has some drawbacks, and for example it's not possible to translate them. therefore, i finally bit the bullet and implemented a format for prisk. basically, information remains the same (such as the mechanism to determine the current country), with one exception: maps are implemented as perl modules. and this allows the use of gettext and other i18n schemes.
this means that maps are now translatable! french translation is of course provided, but help is needed for other languages... (hint, hint)
of course, i wrote an importer to migrate jrisk maps to new prisk format. i also intend to take this opportunity to create some new perl dists with extra maps.
this prisk release shows also a lot of cleanup in the internals, with a partial migration to moose and moosex::poe. using weak_ref for scalar attributes and a tied hash::noref to cache objects allowed to use circular references without having to deal with their problems. finally, prisk is now deferring some module loading to runtime, leading to a faster startup. the changes are plenty, so now is a good time to give it a try! (after v3.112590 has hit your nearest mirror of course)
future releases will continue to see code cleanups and migration to moose. prisk also finally has a configuration system to save user preferences - i "just" need to use this system throughout the code. some dialogs needs also to migrate to prisk's look&feel (thanks tk::role::dialog), and i have some ideas to improve the artificial intelligences & better use poe. not counting other game modes to take into account... oh well, let's say that prisk will keep me busy quite some time! :-)
Showing posts with label translation. Show all posts
Showing posts with label translation. Show all posts
2011-02-03
new dist::zilla command: pot
i just released dist::zilla::app::command::pot, providing dist::zilla with a new pot command (not the plant, you hippy!).
this command allows to (re-)generate a messages.pot file holding all strings to be translated from your module. If a messages.pot file is found, it will update it. otherwise, you will be prompted for a file location, with a default matching Locale::TextDomain settings:
this command allows to (re-)generate a messages.pot file holding all strings to be translated from your module. If a messages.pot file is found, it will update it. otherwise, you will be prompted for a file location, with a default matching Locale::TextDomain settings:
$dzil potyup, underneath it just runs xgettext. and currently, it only finds calls to T() - but i'll add an option to provide your own convention such as _(), gettext(), etc.
[...]
[DZ] Trying to find a messages.pot file...
[DZ] No messages.pot found - enter your own.
messages.pot to use [lib/LocaleData/Foo-Bar-messages.pot]:
[DZ] Running xgettext...
2010-05-17
games::risk speaks your language!
well, maybe not yet, but very soon - as soon as you'll contribute the translated strings! :-)
those days, i feel like working on prisk, the risk clone that i wrote in perl. i added full internationalization, and contributed the first foreign language (french, as you may have guessed :-) ).
you can contribute translations for your language by forking the project, and then sending a pull request with your changes. it should be quite fast, since it only features 73 strings to translate. you know what to do... :-)
note that i also fixed a crash that was appearing sometimes during game startup. i'll now try to find some time to work on bigger topics, such as sanitizing the whole codebase, or adding features...
those days, i feel like working on prisk, the risk clone that i wrote in perl. i added full internationalization, and contributed the first foreign language (french, as you may have guessed :-) ).
you can contribute translations for your language by forking the project, and then sending a pull request with your changes. it should be quite fast, since it only features 73 strings to translate. you know what to do... :-)
note that i also fixed a crash that was appearing sometimes during game startup. i'll now try to find some time to work on bigger topics, such as sanitizing the whole codebase, or adding features...
2009-09-21
first external pandemic translation
i'm really happy to release a new pandemic version, namely 1.092640 (that is first release of 264th day of year 2009 for those that skipped previous entry).
beside the introduction of the medic player (which in itself is interesting), it's with great pleasure that i committed a japanese translation that tomita naoki provided me with. thank you tomita for this first external contribution!
so, if you want to contribute, an easy way to start is by providing a translation for your language! of course, any other contribution is also welcome. :-)
beside the introduction of the medic player (which in itself is interesting), it's with great pleasure that i committed a japanese translation that tomita naoki provided me with. thank you tomita for this first external contribution!
so, if you want to contribute, an easy way to start is by providing a translation for your language! of course, any other contribution is also welcome. :-)
2009-05-12
autoformat and nopaste plugins join padre's nest
after much hesitation, i finally decided to migrate the autoformat and nopaste plugins to padre's svn repository.
not that i prefer svn - after all, i used git for a reason when i started those plugins - but it's handy to benefit of padre's translators for my plugins for free... (btw, if your language is not supported, you're more than welcome to join padre's development team!)
but the nice thing is that gabor told me that if padre gets a good enough git plugin for padre, he will switch padre's repository to git!
good enough here means that even people unfamiliar with git can use it, whatever the platform (yup, windows, i'm staring at you)... and btw, do you remember that there's an on-going contest for best padre plugin?
so what are you waiting for?
not that i prefer svn - after all, i used git for a reason when i started those plugins - but it's handy to benefit of padre's translators for my plugins for free... (btw, if your language is not supported, you're more than welcome to join padre's development team!)
but the nice thing is that gabor told me that if padre gets a good enough git plugin for padre, he will switch padre's repository to git!
good enough here means that even people unfamiliar with git can use it, whatever the platform (yup, windows, i'm staring at you)... and btw, do you remember that there's an on-going contest for best padre plugin?
so what are you waiting for?
2009-04-30
on coders and translators
after reading gabor's latest post, i thought to myself that his proposal can also be reversed...
that is, instead of asking translators for their help (which is fine), let's also propose ourselves pro-actively as translator. i mean, we're a large international community, and we have so much to share rather than just code!
indeed, we are also a human being speaking a given language, before actually being a perl coder...
therefore, i propose myself for some french translations. if you have a project that is in need of french translation, just drop me a line. i don't promise i'll deliver a 100% perfect translation, not even do i promise to deliver it in a given timeframe. but i promise to have a look at it, and try to translate a few strings here and there. and as time goes by, i hope to go through...
so, let's create a pool of translators - who would like to follow?
notes:
that is, instead of asking translators for their help (which is fine), let's also propose ourselves pro-actively as translator. i mean, we're a large international community, and we have so much to share rather than just code!
indeed, we are also a human being speaking a given language, before actually being a perl coder...
therefore, i propose myself for some french translations. if you have a project that is in need of french translation, just drop me a line. i don't promise i'll deliver a 100% perfect translation, not even do i promise to deliver it in a given timeframe. but i promise to have a look at it, and try to translate a few strings here and there. and as time goes by, i hope to go through...
so, let's create a pool of translators - who would like to follow?
notes:
- i don't know if the need for translators is really that big, but who knows? maybe it would be the occasion to think about it for your modules, and help i18n to spread in cpan, leading to more perl usage in the end...
- even if you're french, you can volunteer to spread the load...
- we could even set up some kind of translation market where we could list applications needing translation, and translators ready to help. from what i've heard, it should be dead easy to set this up with a small catalyst app... (hint, hint)
2009-04-28
plugins and translation
localizing an application is important if one wants to take over the world with it. this is why we try to localize padre (the perl ide) and translate it in as many languages as possible. (if padre isn't translated in your language, your help would be more than welcome!)
we are using the standard wx localization framework, which is similar to & compatible with gettext. then, using standard xgettext, msgmerge and msgfmt commands, the translators can do their magic and voilà! padre is translated.
this is working quite well.
but now, enter plugins. indeed, to keep padre as lean as possible, non-core features are deported in plugins. and even if padre is still a young project, there are already quite a lot of plugins for padre.
but how to translate plugins?
first (and stupid) solution would be to extract the strings to be translated and add them to padre's messages file. definitely not a good idea, since padre and the plugins do not share the same release planning, and we would end up with strings mismatch between what padre ships and what the plugin uses.
therefore, the plugin must provide its own translation. but that's a bit difficult, since they are not an application of their own: they are running inside padre, an application that already has its translated messages thank you very much.
so we need a way to have more than one strings catalog open at the same time. i had some troubles finding the correct method within wx documentation, but finally came up with:
$catalog being the catalog containing the new translated strings. and in order not to clash with main catalog (named after the locale, eg "fr-fr" for my current locale), the plugin catalog should be named $plugin-$locale.
but of course, it doesn't work as is. indeed, wx doesn't know where to find this new catalog. so we need to add a new search path to find the locales:
of course, we want padre plugins to be as easy to write as possible, so we don't want plugin authors to have to do this kind of non-sexy things.
therefore, plugin authors just need to define a plugin_locale_directory() method that will tell padre where to look for translated string catalogs. and since the plugins inherit from the base class padre::plugin, they have such a default method which points to the share directory as defined by file::sharedir. therefore, plugin authors don't even need to redefine this method if they're using the install_share instruction of module::install. (i don't like module::install, but that's not the point here)
ok, so plugin authors have one method to add. now they need to extract the strings and translate them (or ask other people to translate them). that's using standard gettext tools, so nothing really gets in the way.
and that's all. because padre handles the loading of new catalogs automatically, as long as they're named $plugin-$locale. that is, if the german translation of Padre::Plugin::SpellCheck is called SpellCheck-de.mo, then padre will find it and make sure that wx translates your plugin.
this is a good thing, because wx is a bitch to program with. that is, you can add a catalog or a catalog path, but you cannot remove them. and you don't want to load all your catalogs at once, to reduce memory load. and padre also takes care of locale switching, unloading previous locales and loading new ones. (unloading as in destroy locale object and create a new one since wx does not know how to remove a loaded locale).
therefore, even for localization, padre plugins are easy to write. why don't you join us and write your own, to have padre behave just how you expect? (using a real programming language that you know and love)
we are using the standard wx localization framework, which is similar to & compatible with gettext. then, using standard xgettext, msgmerge and msgfmt commands, the translators can do their magic and voilà! padre is translated.
this is working quite well.
but now, enter plugins. indeed, to keep padre as lean as possible, non-core features are deported in plugins. and even if padre is still a young project, there are already quite a lot of plugins for padre.
but how to translate plugins?
first (and stupid) solution would be to extract the strings to be translated and add them to padre's messages file. definitely not a good idea, since padre and the plugins do not share the same release planning, and we would end up with strings mismatch between what padre ships and what the plugin uses.
therefore, the plugin must provide its own translation. but that's a bit difficult, since they are not an application of their own: they are running inside padre, an application that already has its translated messages thank you very much.
so we need a way to have more than one strings catalog open at the same time. i had some troubles finding the correct method within wx documentation, but finally came up with:
$locale->AddCatalog($catalog);
$catalog being the catalog containing the new translated strings. and in order not to clash with main catalog (named after the locale, eg "fr-fr" for my current locale), the plugin catalog should be named $plugin-$locale.
but of course, it doesn't work as is. indeed, wx doesn't know where to find this new catalog. so we need to add a new search path to find the locales:
$locale->AddCatalogLookupPathPrefix($directory);
of course, we want padre plugins to be as easy to write as possible, so we don't want plugin authors to have to do this kind of non-sexy things.
therefore, plugin authors just need to define a plugin_locale_directory() method that will tell padre where to look for translated string catalogs. and since the plugins inherit from the base class padre::plugin, they have such a default method which points to the share directory as defined by file::sharedir. therefore, plugin authors don't even need to redefine this method if they're using the install_share instruction of module::install. (i don't like module::install, but that's not the point here)
ok, so plugin authors have one method to add. now they need to extract the strings and translate them (or ask other people to translate them). that's using standard gettext tools, so nothing really gets in the way.
and that's all. because padre handles the loading of new catalogs automatically, as long as they're named $plugin-$locale. that is, if the german translation of Padre::Plugin::SpellCheck is called SpellCheck-de.mo, then padre will find it and make sure that wx translates your plugin.
this is a good thing, because wx is a bitch to program with. that is, you can add a catalog or a catalog path, but you cannot remove them. and you don't want to load all your catalogs at once, to reduce memory load. and padre also takes care of locale switching, unloading previous locales and loading new ones. (unloading as in destroy locale object and create a new one since wx does not know how to remove a loaded locale).
therefore, even for localization, padre plugins are easy to write. why don't you join us and write your own, to have padre behave just how you expect? (using a real programming language that you know and love)
2009-01-15
hats off to translators!
i'm the kind of guy who prefer (most of the time) using the english locale for the applications i'm using.
however, being part of padre's development team, i'm updating the french locale (we try to remove everything that can be a barrier for people new to padre).
and this made me realize how time-consuming and difficult it is to correctly translate an application. indeed, you don't understand the hard work needed for a task unless you are to do this task yourself...
so, my hat off to the many translators that are working on open-source projects: even if your contribution has a lower profile than code, your task is nevertheless important!
ps: and if you think that you could:
however, being part of padre's development team, i'm updating the french locale (we try to remove everything that can be a barrier for people new to padre).
and this made me realize how time-consuming and difficult it is to correctly translate an application. indeed, you don't understand the hard work needed for a task unless you are to do this task yourself...
so, my hat off to the many translators that are working on open-source projects: even if your contribution has a lower profile than code, your task is nevertheless important!
ps: and if you think that you could:
- make a better translation job than me
- contribute a translation for your language
- or even add features
Subscribe to:
Posts (Atom)
