official (momanager) language packs

[L18L]

Alright, I have tried to resolve the problems with transLANG, seems OK:

http://distro.ibiblio.org/quirky/quirky ... 150309.pet

Thank you.
Tested

One small addition, a refresh
needed for the furious multi language translators only:
Insert

Code: Select all

refresh

after line 173

Code: Select all

#150309 do not allow transLANG to be changed to anything other than current locale
# (note, if was allowed, would have to check /usr/lib/locale has it, but I still don't like idea of translating to a different language then current locale).
xtransLANG="$(grep '^transLANG' $CONFIG | cut -f 2 -d '=' | cut -f 1 -d ' ')"
if [ "$(echo -n "$ORIGLANG12" | grep "$xtransLANG")" == "" ];then
 pupdialog --background '#FF8080' --msgbox "Sorry, but you cannot change transLANG to anything other than the current locale, '${ORIGLANG1}' or '${ORIGLANG12}'. Changing transLANG to '${ORIGLANG1}' in file ${CONFIG}" 0 0
 sed -i "s%^transLANG=.*%transLANG=${ORIGLANG1} #${ORIGLANG1} or ${ORIGLANG12}%" $CONFIG
 refresh #150309
fi

[L18L]

wrong thread, sorry.
http://www.murga-linux.com/puppy/viewtopic.php?p=832907

[ASRI éducation]

momanager-20150309.pet

After a first translation, enabling momanager is not possible.
I need to do further testing to understand what is happening.

Code: Select all

# momanager 

** (gtkdialog4:9144): ERROR **: gtkdialog: Error in line 20, near token 'string': syntax error

/usr/sbin/momanager: line 1626:  9018 Terminated              yaf-splash -bg orange -text "Please wait, scanning files..."

Regards,

[L18L]

ASRI,
please try refresh (use button or delete directory /tmp/momanager) then restart momanager from console again.
Which Puppy are you using at the moment?
Thank you

[ASRI éducation]

please try refresh (use button or delete directory /tmp/momanager) then restart momanager from console again.
Which Puppy are you using at the moment?

You're right, a simple restart of X enough.
Thank you for the reply and sorry for the disturbance.
I'm using a puplet based on Precise 5.7.1 and woof-CE.
Regards,

[L18L]

You're right, a simple restart of X enough.

Glad to know there is no bug (detected now)

[L18L]

Anyhow, there is a new version now at initial post page number 1.

some bugs fixed thanks to chief tester Bert.

Nothing really new, should be good somehow for Quirky and Fatdog, too.

[ASRI éducation]

Anyhow, there is a new version now at initial post page number 1.

some bugs fixed thanks to chief tester Bert.

Merci !

[vicmz]

I'm still getting the same momanager error as ASRI, after restaring X several times and all (April 7.0.4.1).

Code: Select all

# momanager
sed: -e expression #1, char 0: no previous regular expression
sed: -e expression #1, char 0: no previous regular expression

** (gtkdialog4:32342): ERROR **: gtkdialog: Error in line 11, near token 'string': syntax error

# 

Thanks to L18L's refresh mode, I was able to backup /tmp/momanager to check all refreshed files manually through Poedit from another puppy, however that goes for existing translations only. I was able to create just one non-existing translation. (Related topic: Has anyone compiled Poedit for April yet?)

The latest woof2 langpack_es is compatible with Quirky, it just needs some updating. It's available here:

http://murga-linux.com/puppy/viewtopic.php?t=76948

The reason why I haven't tested April until just now is that I haven't got enough RAM in my home computer to run April (512 MB), so I'm booting from CD at work (4 GB).

[L18L]

If there is any error in the code of the script MoManager cannot do its job, I guess.

It would be helpful to know the source of that non-existing translation.

Post (or PM) that script please and I will look what I can do.

Changing the code of the script requires always restart ( and refresh which deletes /tmp/momanager ) of MoManager.


----
Why not full install April to a partition?

[ASRI éducation]

I just created a Puppy Precise version based on the latest version of woof-ce-testing (20150611).

My problem: I can not translate the last Zigbert interfaces.
momanager does not show me the files to translate.

An example: how do you translate pdesktop Apps?

Thank you in advance for your advice.

[don570]

Just a suggestion --->

Do the translation in a Puppy distro that is working correctly and bring the
mo files into your Precise distro.

Certain versions of momanager would not show the list of gettext'd scripts
on left side of pane.

______________________

[xanad]

I just created a Puppy Precise version based on the latest version of woof-ce-testing (20150611).

My problem: I can not translate the last Zigbert interfaces.
momanager does not show me the files to translate.

An example: how do you translate pdesktop Apps?

Thank you in advance for your advice.

pdesktop has no the 'export' to momanaqer, if you want try this in attachment
note: what other apps are not read by momanager?

[L18L]

Code: Select all

#151001 translate also .md files (see function get_prop), use AUTHORSPECS in write.log, some code clean up
#151010 fixed pot for mdview; added path of zigbert's stardustlib

What's new

documentation files in .md format can be translated by momanager now. All about jamesbond's mdview
POT files for TEXTDOMAINS from .md files are showing full path script and line number as usual now.

zigbert's libstartdust located under /usr/lib had never be found by momanager before.
Now it is simply managed by having added path of libstardust in momanager's find GETTEXTSCRIPTS.

Download as usual from first page.

[step]

documentation files in .md format can be translated by momanager now.

Thanks. Can you please show me an example of how a shell script would invoke mdview to show multi-language documentation?

[L18L]

documentation files in .md format can be translated by momanager now.

Thanks. Can you please show me an example of how a shell script would invoke mdview to show multi-language documentation?

There is nothing special to invoke from a shell script.
But let me make it clear by comparing with shell script.

In shell script it is:

Code: Select all

export TEXTDOMAIN=atextdomain

In mdview it is:

Code: Select all

 %%textdomain anothertextdomain

shell is looking for translations for each message marked by gettext ' '

mdview is looking for translations for each line (except those started with tab).

That's it.

Example: see http://www.murga-linux.com/puppy/viewto ... 714#865714

---

mdview is jamesbond's mdview available for fatdog in fatdog's package manager gslapt, maybe also in woof-CE soon.

[step]

I finally get it! The shell isn't involved in handling localized md documents; mdview does everything by itself. I like it. So a shell script can use mdview to show localized help files by simply including the classic stanza

Code: Select all

# set up localization
TEXTDOMAIN=name_of_shell_script_text_domain
export TEXTDOMAIN

# show help document
mdview "help.md"

for "help.md" like

Code: Select all

%%nopot yes 
%%textdomain name_of_shell_script_text_domain 
%%nopot no

# SHELL SCRIPT HELP FILE
Bla bla,

Did I get it right?

Actually, I'm still confused. Suppose that a shell script has its own localized messages and displays a localized md file. How should TEXTDOMAIN and %%textdomain be specified? As the same name? If so, there would be a single .po file that mixes the shell catalog with the md catalog? How would I build the source pot file in this case?

[L18L]

I finally get it! The shell isn't involved in handling localized md documents; mdview does everything by itself. I like it. So a shell script can use mdview to show localized help files by simply including the classic stanza

Code: Select all

# set up localization
TEXTDOMAIN=name_of_shell_script_text_domain
export TEXTDOMAIN

# show help document
mdview "help.md"

for "help.md" like

Code: Select all

%%nopot yes 
%%textdomain name_of_shell_script_text_domain 
%%nopot no

# SHELL SCRIPT HELP FILE
Bla bla,

Did I get it right?

Maybe a bit "too" right.
You have declared and exported a TEXTDOMAIN in the shell script.
Thus your help.md can be just:

Code: Select all

# HELP

Bla bla,

Declaration of %%textdomain inside .md is just for use of Puppy's momanager which cannot mix and match different METHODs in a TEXTDOMAIN.

Actually, I'm still confused. Suppose that a shell script has its own localized messages and displays a localized md file. How should TEXTDOMAIN and %%textdomain be specified? As the same name? If so, there would be a single .po file that mixes the shell catalog with the md catalog? How would I build the source pot file in this case?

Yes, do it manually:
append output of mdview --po ... to existing pot file.

If this is for your findnrun, try it this way and there is hope for momanager will use your "hand made" pot file.

[mavrothal]

@L18L
I just hacking your momanager a bit but then I thought I might not need to rediscover the wheel and ask.

The idea is to have momanager scan rootfs-skeleton and rootfs-packages in woof-CE and generate the pot files that can be then used for translations, each language in its own git folder.
For general use momanager could be modified to accept user-defined input and output directories if it does not already (does it ?).
This should not be too hard (from my little hacking).
What would be tricky I think, would be to go through existing pot and po files and change only what is new. And I guess for the pot files it could even rewrite them but you sure need to keep existing translation strings in the po files that are unaffected from the changes in the original scripts.

I know there are more complicated and efficient approaches for collaborative translations (pootle comes to mind) but I have the feeling that most translations are a single (or 2) person show.

Any thoughts?

[L18L]

One note firstly, it is and I hope it will always be Barry's momanager.
I mean the idea and practice of this "all-in-ine" script for translating an entire distribution.
My additions came from practical translating, e.g. sorting,tunig for speed, caching, using fuzzy,etc
ASRI gave some input too
Barry again, (see comments in the script) could upgrade some messages about quirky and woof-Q
Thus any useful input of mavrothal would be appreciated.
Momanager was meant to be for translators only.
Developers when testing their work in progress, not being able to use the command line tools, should manually delete the actual pot file in /tmp/momanager if there have been changes concerning gettext then mightbe they could momanager too.

The idea is to have momanager scan rootfs-skeleton and rootfs-packages in woof-CE and generate the pot files that can be then used for translations, each language in its own git folder.

Sounds good. Would woof-Q be allowed to use them too?
BTW, there are many messages that contain "Puppy" or "Quirky".
Using a variable for this would be very nice.("Puppy Slacko", "Puppy Tahr", ...) . Building a langpack would be changed.

For general use momanager could be modified to accept user-defined input and output directories if it does not already (does it ?).
This should not be too hard (from my little hacking).

There is a /root/.config/momanager.conf, defining output directory o f language, e.g. pt or pt_BR
Input is hardcoded at the moment, see "#find all gettext'ed scripts...", you are right: not too hard to change.

What would be tricky I think, would be to go through existing pot and po files and change only what is new. And I guess for the pot files it could even rewrite them but you sure need to keep existing translation strings in the po files that are unaffected from the changes in the original scripts.

No need for tricks and guesses. msgmerge is our friend.

I know there are more complicated and efficient approaches for collaborative translations (pootle comes to mind) but I have the feeling that most translations are a single (or 2) person show.

... the big advantage of our momanager IMHO: it is included and can be used immediately by anybody. Sharing their works is not everyone's hobby though. .

puppy localization [solved]

woof-(2|CE|Q) localization to be solved