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 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.

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]
Címzett: "Development discussion for LedgerSMB" 
[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 -> 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
>
>
>
>
>
>
------------------------------------------------------------------------------
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

Reply via email to