Pcreole programmable application + nme (creole converter)

[mcewanw]

Changes

3.0.1. Small gui now "remembers" SD_, SF_, TD_, and TF_ values on QUIT

Hopefully this will be the "stable" version for a while now ... Sorry in advance if any new bugs are discovered ... :-)

[L18L]

... Sorry in advance if any new bugs are discovered ...

in wary5.11.57 fresh frugal install running as fido.

pcreole 3.01 downloaded and installed

In created .po translate helptxt msgstr to target lang

/usr/share/locale/en/LC_MESSAGES/pcreole missing

[mcewanw]

in wary5.11.57 fresh frugal install running as fido. :)

pcreole 3.01 downloaded and installed

In created .po translate helptxt msgstr to target lang

/usr/share/locale/en/LC_MESSAGES/pcreole missing :wink:

Hmmm... But pcreole.mo is in the dotpet int he correct location okay. And it all works fine on Wary 5.0. But you are using wary5.11.57 with fido. Could you try changing the permissions on the en file pcreole.mo - temporarily to read, write and execute for everyone to see if it is then found? (how about the de pcreole.mo Help?) Might need to check permissions on the directories it is in too - should be a minimum of read and execute for containing directories I think.

If it is a permissions problem, we need to determine if it is a problem needing fixed in wary5.11.57 or in pcreole... If permissions are wrong on the containing directories (which seems unlikely) that would be a wary5.11.57 bug I think; otherwise I need to know the minimum permissions to put on the file itself. Currently I do have it as Read for Everyone (the World of Others), Write for Root user only, but no-one to execute it. I would have thought that was correct, but perhaps execute permission is required for everyone?? And why does it say "pcreole" missing, rather than "pcreole.mo" missing?

[L18L]

...
And why does it say "pcreole" missing, rather than "pcreole.mo" missing?

That was me saying pcreole missing, should have been /usr/share/locale/en/LC_MESSAGES/pcreole.mo missing
Sorry, my quickshot was wrong.
It is not missing.
And permissions are OK.

But reproducing what has been happening I am able now to explain.

installed preole without German NLS
pcreole started showing the texts in English like expected
Help showing
In created .po translate helptxt msgstr to target lang
That was not expected by me but now it is clear.

gettext worked:
my LANG is de
no /usr/share/locale/de/LC_MESSAGES/pcreole.mo found
so gettext returned the msgid In created .po translate helptxt msgstr to target lang

May way to show the help:
LANGUAGE=en pcreole everything like expected
or
LANGUAGE=de:en pcreole everything like expected
gettext tries de and if not found uses en for each single msgid

Anyway, what can be a concluded from all of this?
Every new user (except the LOCALE=en...) could stumble into the same trap
This trap is caused by your creative use of gettext for the help.

How to avoid the trap?
- use gettext just in the intended way or
- create a workaround

workaround:
create a code snippet which is setting LANGUAGE to <user's langcode><colon>en
and put it at the beginning of pcreole script.

Here a quick and dirty one:

Code: Select all

LANGUAGE="`echo ${LANG:0:2}`:en"

Why dirty?
Working correctly just for 2-letters codes
Not for Portuguese of Brazil (pt_BR) and Chineses

[mcewanw]

This trap is caused by your creative use of gettext for the help.

How to avoid the trap?
- use gettext just in the intended way or
- create a workaround

workaround:
create a code snippet which is setting LANGUAGE to <user's langcode><colon>en
and put it at the beginning of pcreole script.

Oh... Now I see what you mean. Hmmm... I don't really want to clog up the main pcreole script with the whole help text in english - since that also swells the sizes of all the .po and resulting .mo files, but I'll think about it or maybe adopt your suggested workaround or something like it as a compromise... As things stand it certainly encourages users to make new translation files... :-)

Of course copying the en pcreole.mo into the relevant locale location would also bring back the English version of the help button text.

[L18L]

export needed
/usr/bin/pcreole line 34 changed from blank to:

Code: Select all

export LANGUAGE="`echo ${LANG:0:2}`:en"

tested:

# LANGUAGE=bla pcreole
#
# echo $LANGUAGE

#

pcreole's behaviour was like expected: everything in English inclusive complete help

I am hoping there will be a day when I will first test and then post

[mcewanw]

Hopefully this will be the "stable" version for a while now ... Sorry in advance if any new bugs are discovered ... :-)

Changes

Pcreole 3.0.2. English help button text now provided by default until language dotpet installed.

@L18L: Whilst your suggested method works, it is indeed a workaround to compensate for some missing program logic for the special case you reported on. I wasn't happy letting pcreole change system LANGUAGE value since I prefer the system to look after all locale setting matters. It was however easy to address the issue as it turns out: I simply altered the relevant Pcreole program logic so that a provided english help button text is loaded by default. Another advantage of the change is that en locale pcreole.mo is no longer required at all.

Hoping this is the stable one! :-)

[mcewanw]

... oh well... maybe this time!

Recent Changes:

Pcreole 3.0.3. Removed refs to /root in /etc/pcreole_default.rc; now using $HOME

Pcreole 3.0.2. Changed program logic so that en help button text is always provided by default.

Also see above post and download from first post in this thread.

EDIT: Using the gtkdialog3 from Puppy431, I also now have Pcreole running successfully on a RedHat Enterprise Linux system (RHEL5.2) as a normal user.

[L18L]

... oh well... maybe this time!

3.0.3 installed as user fido: successful

The password for root is asked.
Name of the application that required the password was:
/sbin/pup_event_frontend_d

This seems to be a default value for /usr/sbin/askpass but I don't know how to use it in the intended manner

http://bkhome.org/blog/?viewDetailed=02284

Edited
It is just my observation, no show stopper