http://blogs.perl.org/users/aristotle/2011/04/stop-using-maketext.html
It seems Locale::TextDomain is the current way to do it.
http://search.cpan.org/~guido/libintl-perl-1.23/lib/Locale/TextDomain.pm
Lyle
On 19/10/2014 01:15, Chris Travers wrote:
On Sat, Oct 18, 2014 at 4:06 PM, Lyle <[email protected]
<mailto:[email protected]>> wrote:
From what I read (some years ago) Perl's Maketext deals with this
issue and several others.
That is what we are using. On the surface it looks like it does,
until you dig deeper and find that the %d means something completely
different when using Locale::Maketext::Lexicon::Gettext than it does
when using gettext itself.....
Lyle
On 17/10/2014 14:05, Chris Travers wrote:
On Fri, Oct 17, 2014 at 5:46 AM, Pongrácz István
<[email protected] <mailto:[email protected]>> wrote:
Hi,
Regarding our pseudo-gettext files, I think it is a good
format, at least one can use free softwares to translate it,
even simple txt editor.
In the other hand, labels in general has some issues, due to
that, English words usuall have different meanings in
different context. Like 'to' means recipient in email
context, date in time context etc. The other one is the
'account' and several other words.
In this case, it is hard to translate correctly to a specific
language.
Please correct me, but when I translate a word, like 'to', I
cannot manage that, where to use this translation.
I am sure prepositions are problematic there.
I saw other solutions, where almost every labels/texts has
its own label (identifier) and the translator could translate
like this:
* contact_account_creditlimit_label="Credit limit" (in
english file)
* contact_account_creditlimit_label="Hitelkeres" (in the
Hungarian file)
I also like the idea of some online systems, where the user
in "dev mode" is able to rewrite/translate the label while
he/she is using the system, clicking on a little icon.
In GNU Gettext you can use contexts to solve this problem. Have
one string with different contexts, specify the desired context
at translation time and away you go. Our modules do not support
this however....
It's a shame because GNU Gettext is actually very mature. I am
almost wondering if we need to start another GNU Gettext module
since none of the ones I saw on CPAN seemed to work properly
(maybe even use XS and create it as a language binding to the GNU
utilities).
I know, it is not only about 1254, but translation
infrastructure.
What do you think?
Cheers,
István
----------------eredeti üzenet-----------------
Feladó: "Chris Travers" <[email protected]
<mailto:[email protected]>>
Címzett: "Development discussion for LedgerSMB"
<[email protected]
<mailto:[email protected]>>
Dátum: Thu, 16 Oct 2014 23:05:39 -0700
----------------------------------------------------------
Hi;
In the process of resolving various issues on bug 1174,
issues with the Hungarian translation, it was found that
Locale::Maketext::Lexicon and GNU gettext do not have
compatible handling of %. As I have looked further into the
code it looks like only a very narrow subset of gettext
formatting functions are supported by our current libraries
because parameterization is handled in fundamentally
different ways.
GNU Gettext uses sprintf with appropriate qualifiers, and so
% has to be escaped as %%. Locale::Maketext uses numeric
identifiers with non-numeric ones being method names. What
this means is that our .po files aren't really po files, but
things that just kind of look like po files.
Initially we settled on gettext files because we wanted to
have a standard format. However this is not what we have
now. So the question is, going forward (1.5 and beyond) do
we want to continue to use pseudo-gettext files? Or do we
want to move to something else? If we side with the current
status quo we certainly need to document it.
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible.
No vendor lock-in.
http://www.efficito.com/learn_more
------------------------------------------------------------------------
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push
notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No
vendor lock-in.
http://www.efficito.com/learn_more
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push
notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
