Forum > Translations
I18N and maintaining PO files
dbannon:
At great personal risk, I am afraid I must disagree with you Thaddy.
The FPC/Lazarus approach seems to be --long-option=somevalue. Application.GetOptionValue() for example will not return a long option's value if its seperated with a space instead of an equals sign. CheckOptions() returns an error if we tell it a long option should have a value.
Using a space, Application.GetNonOptions() gives an exception if we tell it a long option should have a value. If we lie and say it should not return a value, GetNoOptions() returns the (space separated) value as a non-option parameter.
GNU https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html, says long options should use the equals sign if they return a value.
I do agree its very common practice to use a space, the C getopt will use it but its not the way we normally do it here in Lazarus land. Lazarus itself takes '='. Think of --pcp=somepath ?
I do think it would be a horrible mix if I was to tell my users that some options to the app require an equals and some require a space !
Its a pretty simple change to have DefaultTranslator accept either an equals or a space and help pages would look a lot prettier !
Davo
Thaddy:
--- Quote from: dbannon on April 23, 2019, 10:05:50 am ---At great personal risk, I am afraid I must disagree with you Thaddy.
--- End quote ---
People who actually know me can verify I do not cause any physical nor psychological harm, except the occasional proud when somebody is wrong.
The point I am making is that there are standards. You should adhere to standards. Not to whatever seems comfortable on windows only...
dbannon:
--- Quote ---...Not to whatever seems comfortable on windows only...
--- End quote ---
Wow, I expected a serve but not to that extent. To suggest I'm a Windows user ....
For your information, been a full time Linux user most of my computing life. Managed several Linux based machines that were listed on the Top500. And a (sort of) Linux machine that was the biggest system south of the Tropic of Cancer.
But you are right, standards are important. I have sat on several standards establishing bodies and one thing I know is we can always squeeze in one more standard !
Seriously, (and the above is not meant seriously) if you care to re-read my last post, you will see I was basing my argument solely on standards. The standard way of doing command line options in the Lazarus world. The standard enforced by FPC/Lazarus tools. The standard recommended by GNU - er, where have I gone wrong ?
Davo
marcov:
--- Quote from: Thaddy on April 23, 2019, 10:22:41 am --- You should adhere to standards.
--- End quote ---
There is no standard. libgettext intercepts params on unix, but we don't use libgettext, so our parameters work differently. (and e.g. Lazarus allows setting language persistent without messing with environment variables or cmdline parameters)
wp:
In the attachment I am posting a simple demo supporting translations, and it works as I would expect it.
* The language on my system is German --> when I run the program as it is the GUI comes up in German. This is because unit "DefaultTranslator" is included in "uses" (it contains initialization code to determine the system language). Without it it would select English, the original language of the demo program.
* When I want the program to be in French I can use commandline parameters: "--lang fr" or "-l fr" (without quotes) (Indeed, having to switch from the Lazarus command line parameter syntax to the GNU syntax here is confusing. Why don't you write a bug report/feature request and let Maxim Ganetzky decide who maintains the language subsystem of Lazarus?)
* Requesting a Spanish translation by clicking on the button works, too. Note that the Spanish translation file is "project1.es_ES.po" here, and therefore, the language code to be used in the SetDefaultLang call must be "es_ES".
Navigation
[0] Message Index
[#] Next page
[*] Previous page