Hi everyone
We are nearing the end of our release work for Gazelle B, scheduled for mid-December!
For all developers in the community – if you have a patch to submit and want to be considered in this release, we need this by Thursday November 5th at the latest. That is our target date for Feature Complete, when we will begin bug fixing for the release. If you do not have it ready by then, please go ahead and submit and we will take a look at it for the next release. The earlier you are able to submit the patch the better so there is time to review the patch. Let us know if you have any questions!
Thanks!
Kay
Also, if you have a new feature to submit, please create a new acceptance test which covers the typical use case for the feature. This can be done as a second patch if desired. This will help reduce the risk of regressions being undetected in the new feature and assist us in the functional test effort for Gazelle B!
Details on writing acceptance tests can be found here: http://www.mifos.org/developers/wiki/WritingAcceptanceTests. I can also help point you to an existing example that best matches your feature.
Regards,
Jeff
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Hi!
We are in the final phase of translating Mifos resources into Hungarian. The information and tools provided on the community sites really helped us a lot, thank you very much!
Most of our struggles originate from the fact that the Hungarian language belongs to the family of Uralic languages (as opposed to English, which is an Indo-European language.) It seems that the current resource-architecture of Mifos gives quite little support to languages with stronger inflection. Based on our experiences we suggest that all common labels (used as pre- or postfixes) should be eliminated*. Take for instance the usage of admin.Manage + admin.accounts strings in the following code snipplet (admin.jsp):
<span class="headingorange"><mifos:mifoslabel name="admin.Manage" /> <mifos:mifoslabel name="admin.accounts" /></span>
In our language the “Manage accounts” expression is incorrect, only “Account management” is right. We tried to overcome the problem by giving an empty string value for admin.Manage and transform the admin.accounts into “Account management” however Mifos replaced the empty string with the default value. (Similar experiences with single space values.) Instead of combining words, labels probably should be considered as independent expressions (thoughts, messages.), which in this particular case means that completely new resource string, e.g.: admin.manageaccounts should be used, just like in the case of admin.manageLoanAccounts.
As far as empty or single space values are concerned: how to avoid plural signs in different labels? If we give “” as a plural sign, the English default (“s”) will be used as a replacement.
Waiting for your kind suggestions and ideas, sincerely yours:
Ferenc Kovács
* The most problematic common strings are: define, definenew, createnew, manage, s, view
Wow, interesting!
> completely new resource string, e.g.: admin.manageaccounts should be
> used, just like in the case of admin.manageLoanAccounts.
Yes, exactly! We will gladly consider patches combining multiple
untranslatable strings into single, translatable phrases.
> As far as empty or single space values are concerned: how to avoid
> plural signs in different labels? If we give “” as a plural sign, the
> English default (“s”) will be used as a replacement.
I don't know the answer to that one, but I would think there should be a
standard means of pluralization that we can take advantage of. Anyone?
>> I have a couple more questions.
I am very pleased to see that :-)))
We are translating v1.3.1 (although I probably gave the translator the resources from the trunk, about a month ago..) We are using poEditor (the open language filter tool was buggy, did not transform the files into xliff correctly) + po2prop utilities (about two months ago I asked Kay to create Hungarian in the Mifos pootle server but he did not really respond - guess you guys have a hard time with the december release - so we moved on...)
As far as my resource-patch questions are concerned: I think the first step could be to transform the languge resource loader so that it could accept empty strings as values (and do not load the default english expressions instead.) It would help us out from most of the trouble (including the plural form issues.) Paralelly I can start to collect all "built-from-parts" expressions so that they could go deprecated and be replaced by new resource strings in the form descriptors.
Hope to hear from you soon:
Ferenc Kovács
________________________________________
Feladó: Adam Monsen [amo...@grameenfoundation.org]
Küldve: 2009. november 3. 21:47
Címzett: Mifos Developer Discussions
Tárgy: [Mifos-developer] Hungarian translation
Hi Ferenc,
Thanks!
-Adam
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
> As far as my resource-patch questions are concerned: I think the first
> step could be to transform the languge resource loader so that it
could
> accept empty strings as values (and do not load the default english
> expressions instead.) It would help us out from most of the trouble
> (including the plural form issues.)
It could be interesting to explore an approach like this as a temporary
workaround. Though it seems like it could cause problems for the
ability to override one translation with a partial translation. The
hope is that in the future we could allow a given installation to
customize strings in their chosen locale by supplying only those strings
they want to override.
> Paralelly I can start to collect
> all "built-from-parts" expressions so that they could go deprecated
and
> be replaced by new resource strings in the form descriptors.
This would be great if you could collect a list of these. We know this
is a problem, but we don't know where all the places that need fixing
are. Compiling this list would be very useful to help get this fixed so
that translations like yours could be done in a standard way.
Thanks for looking into this!
--Van
----
Van Mittal-Henkle
Mifos Software Developer
Grameen Foundation
va...@grameenfoundation.org
I can give you the finalized versions of hungarian locale probably at the end of next week and the list of problematic expressions within less than a month.
> The hope is that in the future we could allow a given installation to
> customize strings in their chosen locale by supplying only those strings
> they want to override.
Exactly! Why is it neccessary to leave the empty (non-translated) elements in the partial po/property files? They should be deleted instead! When the resource loader can not find a given resource it should take the default value (english locale) however when it finds something with an empty string value, it ought to be considered left empty intentionaly. What do you think?
Best regards,
Ferenc
________________________________________
Feladó: Van Mittal-Henkle [va...@grameenfoundation.org]
Küldve: 2009. november 11. 18:33
Címzett: Mifos software development
Tárgy: Re: [Mifos-developer] Hungarian translation
Yes, you're right on here.
A bit of context: the .po files are generated and maintained by
shell scripts in the localizedResources directory. See
http://www.mifos.org/developers/wiki/AdminOnlineTranslationHOWTO for
more information.
We convert to .po format so Pootle can be used for translating. We
convert from .po since Mifos translated strings must be in Java
.properties format.
So, an artifact of this process is .po files with all strings, even
those that are identical to the defaults.
Another option for online translation for Mifos may be
http://translatewiki.net . I met Siebrand Mazeland at the Google
Summer of Code 2009 mentor summit, and he thought translatewiki
could be used to translate .properties files directly. The
translation memory for translatewiki is apparently very large, too.
However, we just need someone with enough time/interest to vet and
implement this tool for translating Mifos.
Only the resource handler lookup method should be modified to handle this option (eg. MessageLookup.java, instead of "return StringUtils.isEmpty(textMessage) ?" some custom "isempty" method could be implemented...)
Ferenc
________________________________________
Feladó: Adam Monsen [hai...@gmail.com]
Küldve: 2009. november 12. 20:44
Címzett: mifos-d...@lists.sourceforge.net
Tárgy: Re: [Mifos-developer] Hungarian translation
> > The hope is that in the future we could allow a given
I'm not sure if that would work; I assumed empty strings had some
special meaning for Template Toolkit.
> Only the resource handler lookup method should be modified to handle this
> option (eg. MessageLookup.java, instead of
> "return StringUtils.isEmpty(textMessage) ?" some custom "isempty"
> method could be implemented...)
Interesting idea... if you or someone could create a patch against the
trunk that makes this possible, we should be able to take a look at it
sometime.