Topic: Is the "#, php-format" string in empty.po a bug
Please check the lang/new_language_template/LC_MESSAGES/empty.po file that contains several lines just being #, php-format.
Is this a bug / cause for some strings to become missing?
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Report Bugs here → Is the "#, php-format" string in empty.po a bug
Please check the lang/new_language_template/LC_MESSAGES/empty.po file that contains several lines just being #, php-format.
Is this a bug / cause for some strings to become missing?
No, this is just formatted string marker added by original gettext suit command msgfmt. As this is just a comment it should not hurt anyway.
Janusz
There are lots of strings with and without a colon(:) at the end - can they not all be consolidated?
Minimizing number of strings would make for quicker translations.
Also ucfirst() can be used to capitalise the first letter of a string to minimize the number of strings in translations as well.
Any bash oneliner to make a quick Google translate and work from there?
No, definitely no. While I can agree there is somein consistency here and there in punctuation, in many places places the same words in english have different meaning, so they cannot be standardized. Also, e.g. 'Sales Invoice:' is used before document number, but there is no sense to have it in transaction type selector on 'Void a Trancaction' page. This problem (if any) should be considered case by case and ther is no chance to solve it with any magic onliner.
Finally, gettext tools automatically reuse translation on new strings, marking such places with '#fuzzy' marker, so the translator can easyily check them and aprove or reject. No need for more automata here.
Janusz
The auto Google translate bash oneliner was requested to make translation easier as native speakers of the language can afterwards correct only the ones that are wrong.
Sales Invoice
Sales Invoice:
The above two could have been handled by just one instance without the colon and the colon could have been hard coded in the scripts. If the colon comes in between the string, then it can be handled individually.
FrontAccounting forum → Report Bugs here → Is the "#, php-format" string in empty.po a bug
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.