TRANSTEXT - Complimentary alternative to gettext

[stemsee]

I have created an alternative mechanism for translating texts, labels in scripts which have already preliminary gettext preparation in the code. My function catches the gettext call and the 'trans' script is used to retrieve translations from google. The translations are saved so that subsequent searches will be local and very quick. The advantage is that no translations need be done manually, also the number of languages available is limited by the number available on google translate. And because the strings are saved locally they can be edited if need be. I call this system 'transtext'.

It could be more 'complimentary' to gettext, if you are willing and able to do the leg work! From what I have read gettext translation files are compiled and 'should be' saved "$TEXTDOMAIN"-"$LANG".mo (LANG=en_GB.UTF-8), that is not the case in FatDog anyway. Gimp is saved as gimp20.mo. The language code is 'filtered' by the directory structure. The application is supposed to call gettext with arguments $TEXTDOMAIN 'msgid'. 'msgid' is the untranslated string. IN my function the "$msgstr" is saved and called using md5sum hashes, so each string is a new file labelled with its own hash signature. This could feasibly be made into a po file still using the hash as 'msgid'. Using hashes has advantages in that if the same string is used in a script in several different places, or in several different scripts, it will always produce the same hash and so not have duplicates. One known problem with md5sum hashes is that it is possible to replicate a hash with different input strings, but I suspect that is rare. The function could easily work with sha256sum or sha512sum as well.

In the gimp20.po file it should have program line numbers followed by 'msgid "$string"', followed by 'msgstr "$translated_string"'. According to what I read, these strings are supposed to get translated either manually or, you would expect, programmatically. After a little effort I was able to translate programmatically a .po file 'msgid "$string"' , and save as a 'msgstr "$translated_string"' in a new .po file... which would then get compiled and saved as a .mo file, with special magic string and formats etc etc ..... I have found that the subsequent files for an app are bigger than those produced with my simpleton function. GNU gettext says retrieval is much faster because of C code. It's a great system, no doubt. But mine is far better ... for me! I have no desire to further 'compliment' gettext with my function ... too much archaic BS to deal with!!!

xscreenshot-20230513T204240.png (160.13 KiB) Viewed 2367 times

[BarryK]

That is very clever!

Would it be possible to check first whether there is an appropriate .mo file, and if not lookup using trans?

[stemsee]

Hi Barry

It has to be possible! I don't know the format of a mo file. But in transtext system one $(gettext 'text') call creates one new file.
I had a look here at mo files, and it's way too complex for my coding ability. But the gettext function could call the gettext script, I imagine, and if it returns 1 then transtext could be made to fill in, I suppose. https://www.gnu.org/software/gettext/ma ... Files.html. But this works for several gettexted scripts I tried, and any language set can be made on first usage, after which very small delays remain. Probably even the gettext script could directly invoke the trans script, if no local translation is found. But that would then be a different system.

Here is the basic function, which could be a script for system wide usage.

Code: Select all

function gettext {
	syslang=$(locale | grep LANG | cut -c6,7)
	unset WORK
	if [ "$syslang" == 'en' ]; then
		echo "$1"
	elif [ "$syslang" != 'en' ]; then
			HANDLE=$(echo "$1" | md5sum)
		if [ -f /root/.transtext/"$syslang"/"$syslang"-"$HANDLE".transtext ]; then
			WORK=$(cat /root/.transtext/"$syslang"/"$syslang"-"$HANDLE".transtext &)
			echo "$WORK"
		elif [[ $(type -p trans) != "" ]]; then
			 WORK=$(echo -e "$1" | trans -e google -no-auto -b -tl "$syslang" &)
			[ "$WORK" ] && echo "$WORK" || echo "$1"
			[ ! -d /root/.transtext/"$syslang" ] && mkdir -p /root/.transtext/"$syslang"
			[ ! -f /root/.transtext/"$syslang"/"$syslang"-"$HANDLE".transtext ] && echo -e "$WORK" > /root/.transtext/"$syslang"/"$syslang"-"$HANDLE".transtext 
		else
			echo "$1"
		fi
	fi
}; export -f gettext

trans fake .gz

trans.gz

(193.03 KiB) Downloaded 54 times

xscreenshot-20230514T181310.png (32.13 KiB) Viewed 2290 times

[stemsee]

search for the $TEXTDOMAIN-$LANG.mo file if found use gettext $TEXTDOMAIN 'msgid' , otherwise proceed with function gettext . Needs improving...

Code: Select all

function gettext {
[ ! "$lng" ] && find /usr/share/locale/$(echo $LANG | cut -f1 -d'_')/ "$TEXTDOMAIN"-"$LANG".mo || find /usr/share/locale/$(echo "$lng" | cut -f1 -d'_')/ "$TEXTDOMAIN"-"$lng".mo
[ $? -eq 0 ] && $(type -p gettext) "$TEXTDOMAIN" "$1" && exit
	[ ! "$lng" ] && lng=$(echo "$LANG" | cut -f1 -d'_')
	unset WORK
	if [ "$lng" == 'en' ];then
		echo "$1"	
	elif [ "$lng" != 'en' ];then
		HANDLE=$(echo "$1" | md5sum | awk '{print $1}')
		#HANDLE=$(echo "$1" | sha512sum)
	if [[ -f "$camino"/transtext/"$lng"/"$lng"-"$HANDLE".transtext ]]; then
		WORK=$(cat "$camino"/transtext/"$lng"/"$lng"-"$HANDLE".transtext &)
		echo "$WORK"
	elif [[ $(type -p trans) != "" ]]; then
			[ ! "$lng" ] && lng="$lang" || lng="$lng"
			 WORK=$(echo -e "$1" | trans -e google -no-auto -b -tl "$lng" &)
			[ "$WORK" ] && echo "$WORK" || echo "$1"
			[ ! -d "$camino"/transtext/"$lng" ] && mkdir -p "$camino"/transtext/"$lng"
			[ "$WORK" ] && [[ ! -f "$camino"/transtext/"$lng"/"$lng"-"$HANDLE".transtext ]] && echo -e "$WORK" > "$camino"/transtext/"$lng"/"$lng"-"$HANDLE".transtext 
		else
			echo "$1"
		fi
	fi
}; export -f gettext

or

Code: Select all

function gettext {
[ ! -f /tmp/"$lng"-"$TEXTDOMAIN" ] && find /usr/share/locale/"$lng"/LC_MESSAGES/ "$TEXTDOMAIN".mo
if [ $? -eq 0 ]; then
	$(type -p gettext) "$TEXTDOMAIN" "$1"
	exit
else
 	touch /tmp/"$lng"-"$TEXTDOMAIN"
fi
	[ ! "$lng" ] && lng=$(echo "$LANG" | cut -f1 -d'_')
	unset WORK
	if [ "$lng" == 'en' ];then
		echo "$1"	
	elif [ "$lng" != 'en' ];then
		HANDLE=$(echo "$1" | md5sum | awk '{print $1}')
		#HANDLE=$(echo "$1" | sha512sum)
	if [[ -f /usr/share/locale/"$lng"/"$HANDLE".transtext ]]; then
		WORK=$(cat /usr/share/locale/"$lng"/"$HANDLE".transtext &)
		echo "$WORK"
	elif [[ $(type -p trans) != "" ]]; then
			 WORK=$(echo -e "$1" | trans -e google -no-auto -b -tl "$lng" &)
			[ "$WORK" ] && echo "$WORK" || echo "$1"
			[ ! -d /usr/share/locale/"$lng" ] && mkdir -p /usr/share/locale/"$lng"
			[ "$WORK" ] && [[ ! -f /usr/share/locale/"$lng"/"$HANDLE".transtext ]] && echo -e "$WORK" > /usr/share/locale/"$lng"/"$HANDLE".transtext 
		else
			echo "$1"
		fi
	fi
}; export -f gettext

[stemsee]

I have an idea: If the function saves also the input string in an original-$HANDLE.transtext file, then in fact the entire script can be translated into any language, including keywords, and placed as a new file and run in /tmp etc. Then when any binary is called (having been renamed in the script by translation) the original-$HANDLE.transtext string would be called to execute the original binary name. Doing that would mean only one translation into one document. Google translate does have word count limits, so that would need to be addressed. Also the gettext function itself would need to remain untranslated (...maybe).

EDIT: first test results in; two translated scripts, the same script, one into chinese the other into German, both end up with reformatting, loss of backslashes, etc. So it wont be easily reversible. The google engine is interpreting some of the functional characters. So that idea looks too difficult to implement. However it seems to contribute towards the possibility that we see in AI programming. That is plaintext programs. So an example would be '# Comments' in a script being the HANDLE for a block of code, which is associated, using hashes. So you open a script and all you see is plain text, then upon running the text through the transtext function, code blocks are substituted in and rebuild a script in /tmp/ which is then run normally, or just run the exported functions in transtext space.

EDIT: for my purposes I would only need a a second function...$(transtextorigin "$string"), for this to work with key words, which are parsable within the program, but would benefit the user to see the words in their language. Might also work with some function names.

[gyrog]

This is interesting.

I am currently working on transforming FrugalPup to support i18n.
The FrugalPup scripts all include a single file caled "frugalpp-common", so I could try your stuff by including the function there.

Just to be clear:
Your code is all included in the "code" windows, the "trans.gz" file is just a copy of the standard translate-shell and is used by your code.
To use your code I need to "SELECT ALL" one of the "code" windows and paste it into my script.
Is that correct?

Which version of your code would be your preference for me to try?

[stemsee]

Hi @gyrog thanks for your interest. The trans.gz is just the standard one floating around, and used in trans_tray by fredx181. I made no alterations to it.

The various function forms here are a bit confusing. I was trying to demonstrate a more universally applicable function, by using /usr/share/locale/$LANG to save translated strings. I also tried to implement a search for already existing $TEXTDOMAIN.mo. However I recommend keeping seperate from gettext, the only similarity is the function is called gettext so it can intercept gettext calls. In my script the variable $lng is supplied by "$2" (e.g. snapp dark en), and exported so it isn't an argument sent to the gettext function. If not supplied the function uses env $LANG to get the system locale language to translate into.

I personally use this function with $camino being path to my app configs. And "$track" being app working directory in /tmp. So you can save the translated strings where you like, but in the future if everyone use /usr/share/locale/$(echo $LANG | cut -f1 -d'_') then we apps will be able to re-use common language string translations which have been named by md5sum hashes. This function also saves the original string but its name (HANDLE) is the preposition 'original' plus the hash of the translation, for future development uses, but not essential. Another assumption in this function is that the script it is in is in Englsh...so if your native language is French then instead of testing for 'en' test for 'fr' ... etc

Code: Select all

function gettext {
	[ ! "$lng" ] && lng=$(echo $LANG | cut -f1 -d'_')
	camino='/path /to /your /save /directory'
	unset WORK
	if [ "$lng" == "$(echo $LANG | cut -f1 -d'_')" ];then
		echo "$1"	
	elif [ "$lng" !=  "$(echo $LANG | cut -f1 -d'_')" ];then
		HANDLE=$(echo "$1" | md5sum | awk '{print $1}')
	if [[ -f "$camino"/transtext/"$lng"/"$HANDLE".transtext ]]; then
		WORK=$(cat "$camino"/transtext/"$lng"/"$HANDLE".transtext)
		echo "$WORK"
	elif [[ $(type -p trans) != "" ]]; then
			[ ! "$lng" ] && lng="$lang" || lng="$lng"
			WORK=$(echo -e "$1" | trans -e google -no-auto -b -tl "$lng")
			[ "$WORK" ] && echo "$WORK" || echo "$1"
			[ ! -d "$camino"/transtext/"$lng" ] && mkdir -p "$camino"/transtext/"$lng"
			[ "$WORK" ] && [[ ! -f "$camino"/transtext/"$lng"/"$HANDLE".transtext ]] && echo -e "$WORK" > "$camino"/transtext/"$lng"/"$HANDLE".transtext
			HANDLE=$(echo "$WORK" | md5sum | awk '{print $1}')
			[ "$WORK" ] && [[ ! -f "$camino"/transtext/"$lng"/original-"$HANDLE".transtext ]] && echo -e "$1" > "$camino"/transtext/"$lng"/original-"$HANDLE".transtext 
	else
			echo "$1"
	fi
fi
}; export -f gettext

[gyrog]

@stemsee,
thanks again for this topic, it's helped me to write a script to translate some text files to support gui display software I'm working on.
This software could use these files, that would be translated only once, in preference to calling gettext every runtime.

Thanks for "trans", it works fine on my old xenialpup, although I use a slightly different command line to yours:

Code: Select all

tdString="$(trans -e google -no-auto -no-warn -b $langs "$transString")"
tdString="${tdString//u003d/=}"

$langs contains the shorthand <source lang>:<target lang>, e.g. "en:fr".
The second line is to convert the binary representation of "=" back into a real "=".

I do wonder about doing automatic translation in real time, since I've noticed that once my script started actually calling "trans",
my script was an awful lot lot slower.
But of course, with your code, this only happens the first time a particular text is encountered.

Of the various versions of your code, based on the little I've read, the one after the "or" is the more "normal".
That's the one I would try.
Unfortunately, I would be a poor test subject, my $LANG is "en_AU.UTF-8".
I've had to resort to testing my gettext scripts, by placing a French frugalpup.mo in /usr/share/locale/en/LC_MESSAGES/

[stemsee]

@stemsee,
thanks again for this topic, it's helped me to write a script to translate some text files to support gui display software I'm working on.
This software could use these files, that would be translated only once, in preference to calling gettext every runtime.

preferable

Thanks for "trans", it works fine on my old xenialpup, although I use a slightly different command line to yours:

Code: Select all

tdString="$(trans -e google -no-auto -no-warn -b $langs "$transString")"
tdString="${tdString//u003d/=}"

$langs contains the shorthand <source lang>:<target lang>, e.g. "en:fr".
The second line is to convert the binary representation of "=" back into a real "=".

That's useful code which I needed two days ago, as I'm testing an idea to translate entire scripts including code. '=' and '\' slash re most problematic.

Of the various versions of your code, based on the little I've read, the one after the "or" is the more "normal".
That's the one I would try.
Unfortunately, I would be a poor test subject, my $LANG is "en_AU.UTF-8".
I've had to resort to testing my gettext scripts, by placing a French frugalpup.mo in /usr/share/locale/en/LC_MESSAGES/

That's why in my scripts I have

Code: Select all

export lng="$2"

then I open the script in any language i choose, including latin 'la'.

[stemsee]

Transtext 'as a live system' works well, speed of presentation depends primarily on a speedy internet connection. Live was the first use I put it to until I figured out local saving and retrieval.

Translation in general.
For truly clear and relevant translations it is necessary to use language in the 'prescribed' way. That is a descriptive grammar and usage describes the way language is used with all its archaic cut-offs, abbreviations, deviations, 'noise', err....and other idiomacies. A 'prescriptive' grammar is the theoretically correct usage, akin to BBC English, or Matriculation English (that's a joke these days....academia is a full of illiterates!). Clear complete, simple sentences are best. Use metaphors and idiomatic expressions in their most typical formats. This way the computer algorithms have a better chance of translating the intended meaning. Computers don't 'know what you mean' they know what you say!

[gyrog]

Would it make sense to have a script that will translate a .po file into transtext, this would "prime the pump" so to speak.
It's easy to generate a .po file using xgettext. If the translator wanted to not translate a particular msgid, they could cut and paste msgid to the msgstr. The script would then store this as a transtext as though it were translated, so that the automatic gettext would not subsequently translate it.

There could also be a utility to provide review of the translated messages, including an option to replace it with the original text,
effectively implementing "no translation for this particular msgid" which is posssible in the current gettext + .mo file.

[stemsee]

The possibilities are there. It's a good idea and I was thinking out code along similar lines. Is your idea two-way ... i.e. transtext uses already translated .po files instead of 'trans' retrieving from google. And .po files regenerated using already created transtext files? It is a good idea to code all those possibilities because I'm sure they will be useful.

Whether using a .po with the transtext hash as msgid. For retrieving a transtext translation ... this is more difficult because of the format of the .po file. In the .po file translated strings are indexed against line numbers, transtext instead relies on hash identification to store and retrieve translations. If you can do it, that would be great. But maybe I don't get your idea clearly. I'd be happy to work with you on this, if you take the lead in the 'x-/gettext' integration, as a way of making use of all the previous labour invested in gettext translations and .po files. In fact this would add transtext functionality in some way to gettext. Is that what you intended?

Code: Select all

echo "This is the help section" | md5sum | awk '{print $1}'

is always the same hash, so many apps use the same string....this eliminates the need of $TEXTDOMAIN string storage and retrieval, so saving on space. There is also no need to store any transtext file in separate language folders, we only do so for human convenience. An editor would remove this need. An editor would only need the original string or msgid passed through md5sum | awk '{print $1}' to retrieve and cat the file and edit the string. Then save back to the same hash handled file. So that function is easy enough. Then those 'human improved transtexts' (HITs) files could be suffixed.

[gyrog]

I've attached a 'po2transtext.txt' file which contains brief specifictaions for a few utility scripts to support transtext.
This explains more clearly what I intended.

[stemsee]

I have completed the code for a working editor, currently using my snapp APP interface. It allows for recreating the hash of a text string to locate the file to be edited, or you can just browse or search a list for hash, then edit then save. Fully working.

I will add it to the gettext function as a standalone editor. I will also save HIT (Human Improved Translations) as .HIT.transtext ... and have an option to give priority to HIT files over non-HIT files on retrieval.

These are just out of context code snippets...

Code: Select all

	export SSID="$1"
	export BSSID="$2"
	export PASS="$3"
	export IDENTITY="$4"
	export PROFI="$5"
	export EDITS="$6"
	export SCALE="$7"
	export DNS="$PROFI"
case "$line" in
	*.transtext) T_TEXT=$(cat "$line")
			A_TEXT=$(while read -r line; do printf "%s" "$line\n"; done <<< "$T_TEXT")
			printf "%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n" "SAVE$KEYWORDS" "$line" "" ""  "$line#$(ls "$camino"/{books,profiles,scenes,notes}/* | tr '\n' '#')" "$ACTIONCMND" "$A_TEXT" "$SCALE" | sed 's/\\n|$//' > "$track"/pay
		exit;;
function trans_editorfn {
	echo -e '\f' > "$track"/yap
	ls "$camino"/transtext/*/* | listformatfn
	printf "%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n" "SAVE$KEYWORDS" "" "" "" "" "" "$A_TEXT" "" > "$track"/pay
};export -f trans_editorfn
	case "$SSID" in
TRANS_EDITOR) T_TEXT=$(echo "$BSSID" | md5sum | awk '{print $1}')
A_TEXT=$(while read -r line; do printf "%s" "$line\n"; done <<< "$(cat $camino/transtext/$T_TEXT.transtext)")
printf "%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n" "SAVE$KEYWORDS" "" "" "" "$camino/transtext/*/$T_TEXT.transtext#$(ls $camino/{books,profiles,scenes,notes}/* | tr '\n' '#')" "$ACTIONCMND" "$A_TEXT" "$SCALE" | sed 's/\\n|$//' > "$track"/pay
exit;;

[stemsee]

I've attached a 'po2transtext.txt' file which contains brief specifictaions for a few utility scripts to support transtext.
This explains more clearly what I intended.

Your ideas are logical, systematic, coherent and simple to implement ... should be very easy to complete, even as a single function with a case statement.

General Criticisms

In the current .po/.mo system of translation, the translator can choose not to translate some "msgid" by leaving the "msgstr" field empty.
The result being that the gettext() call in the running program will return the original text.
I know some translators do not translate the "button" labels, or the "title".
Whatever is done, needs to preserve this capability.

Don't $(gettext 'Anything you don't want translated') - solves that issue at source and saves work. However for backwards compatibility your solution sounds fine.

Downsides of the transtext automatic gettext() translation by itself:
There is no ability to not translate a message that is processed by gettext().
There is also no facility for a human review of the translation.

The coder simply doesn't add gettext parentheses to the script! Also notice the test of '$lng == 'en' ' to prevent translation to 'en' specified language, just needs adapting. But I could add a confirmation popup with 'original' or 'alt.$lng' or 'supplied.$lng' - and this popup could activate after retrieving supplied-$lng translation so that the string can be edited before being saved either to .po or transtext. That could be a lot of popups (with timeouts accepting translation), but only happens once per script. Of course this would be an option. These options address all the failings pointed out....I think!

EDIT: This popup gui with three buttons for quick use, and a text-info display/editor of translation and another viewer with alt.$lng, and another with "original.$LANG". The three buttons would be 1) Accept Trans. 2) No Trans. 3) Alt Trans ... this final option depends on supplying a second choice language either at this stage so requiring further translation request, or before thus providing a preview with the alternate language . I like this idea because as a polyglot my labels could be in mixed languages for one app....how cool would that be!? In fact just being able to edit at this stage means the editor can supply the text in any language they choose without calling a further translation request, although that option would be available.

[gyrog]

Don't $(gettext 'Anything you don't want translated') - solves that issue at source and saves work. However for backwards compatibility your solution sounds fine.

As a developer who is not a translator, I want to make "everything" available for translation, and leave the choice to the translator e.g. some might translate the 'title' others might not. So, a solution for "no translation for this message" cannot depend on the gettext() call in the source.

As for the rest, it looks like you have things moving along.
But it needs to progress to "published" code, even if that's just a '.tar.gz' file in this forum topic.
Unfortunately, I won't be able to do any coding on it for about 2 weeks, (life sometimes interferes).
I'll reply again on this forum topic when I am available.

Note: I was a complete novice at this translation stuff until a few weeks ago.

[stemsee]

I have completed the task as I suggested by adding the popup to gettext function.

An alt_lng="$3" or "$2" depending on whether it is an argument for a script or the gettext function, and provides the alternative language/dialect/'dictionary entry' string. Can also be for using an alternative translation engine instead of google. I'm sure a translation engine in China will do a better job of translating into Chinese than google....and likewise for other languages/dialects.

Of course this will become either a standalone script for system use or an external function to be sourced, or as is now a function to be added.

The thing left to do is to 'manage' (read and write) the .po file. From what I looked at it, just read and operate on it line by line might be the simple option. I prefer simple options (RISC).

Thanks for your input @gyro

[gyrog]

@stemsee, you are welcome.
FYI, an initial .po file can be created from the source files using 'xgettext'.
(But you probably already know that.)

[gyrog]

Just a few stray thoughts on transtext.

1. It should work any way, not just from English.
If a French coder writes a utility that displays it's messages in French,
transtext should work to translate it to English when I run the French utility.

2. It must handle multi-line messages, but then it looks like it already does.

3. There could be situations where multiple langauges need to be installed on a single Puppy.
So maybe storing the transtext files under a "$lng" directory is useful for more than people optics.

4. There may be another way to specify that a msgid has been deliberately not translated.
I found this on a web forum, use 'msgstr "\0"' or use a Unicode Character 'ZERO WIDTH SPACE' (U+200B).
I ran a little test on the "\0" method and $WORK comes back as empty.
So the code could be:

Code: Select all

	if [[ -f "$camino/$lng/$HANDLE.transtext" ]]; then
		WORK=$(cat "$camino/$lng/$HANDLE.transtext")
		if [ "$WORK" ]; then
			echo "$WORK"
		else
			echo "$1"
		fi

5. Is there any way to "clean-up" the '.transtext' files?
If a key gets changed from "A walk in the park" to "A walk in a nearby park",
there will be an orphaned '.transtext' file for "A walk in the park".

6. Alternative approach to .po support utilities:

a) Process an untranslated .po file creating '.transtext' files using automatic translation.
Skips any "msgid" that already has a '.transtext' file.
Has an option to run in "interactive' mode, where user is presented with an editable field containing the google translation,
with just an "Ok" button. If field is empty then "\0" is written, else field contents are written.
This can be re-run if google barfs part way through.

b) Process untranslated .po file, retrieve any '.transtext' file, interactively reviewing the entry.

c) Process untranslated .po file, generating a translated .po file based on the current content of '.transtext' files.
Not interactive.

d) Process translated .po file, updating '.transtext' files, where necessary.
If "msgstr" is "", write "\0".
Not interactive.

Scripts c) and d) shouild make currrent experienced translators feel more comfortable with transtext,
because they can do their normal thing, but instead of converting the final .po file to .mo file,
they run script d), without ever seeing an automatic translation.

[stemsee]

Just a few stray thoughts on transtext.

1. It should work any way, not just from English.
If a French coder writes a utility that displays it's messages in French,
transtext should work to translate it to English when I run the French utility.

2. It must handle multi-line messages, but then it looks like it already does.

3. There could be situations where multiple langauges need to be installed on a single Puppy.
So maybe storing the transtext files under a "$lng" directory is useful for more than people optics.

4. There may be another way to specify that a msgid has been deliberately not translated.
I found this on a web forum, use 'msgstr "\0"' or use a Unicode Character 'ZERO WIDTH SPACE' (U+200B).
I ran a little test on the "\0" method and $WORK comes back as empty.
So the code could be:

Code: Select all

	if [[ -f "$camino/$lng/$HANDLE.transtext" ]]; then
		WORK=$(cat "$camino/$lng/$HANDLE.transtext")
		if [ "$WORK" ]; then
			echo "$WORK"
		else
			echo "$1"
		fi

1) Yes, I just didn't implement the variable instead of 'en', as my scripts are in English. So how to set the variable was the issue?? Do I let the gettext function retrieve the first translation requesting details of the source language and auto set the 'script language variable' as opposed to the host $LANG variable and the supplied $lng variable.
4) I don't have a method in place, so I could use this.

5. Is there any way to "clean-up" the '.transtext' files?
If a key gets changed from "A walk in the park" to "A walk in a nearby park",
there will be an orphaned '.transtext' file for "A walk in the park".

In transtext there are no orphaned files .... if $TEXTDOMAIN was being used then they could be deemed as orphan files. But as it is they are just translated strings waiting to be called up for service. Deleting them to save space is wasting work done! Anyway the post editor can delete any file by double-clicking in the list. Accidental deletion results in a new retrieval from google.

6. Alternative approach to .po support utilities:

a) Process an untranslated .po file creating '.transtext' files using automatic translation.
Skips any "msgid" that already has a '.transtext' file.
Has an option to run in "interactive' mode, where user is presented with an editable field containing the google translation,
with just an "Ok" button. If field is empty then "\0" is written, else field contents are written.
This can be re-run if google barfs part way through.

b) Process untranslated .po file, retrieve any '.transtext' file, interactively reviewing the entry.

c) Process untranslated .po file, generating a translated .po file based on the current content of '.transtext' files.
Not interactive.

a) I think I have the code ready just need to incorporate a .po template somehow. b) & c) in my desired usage would be .po file managed/built by transtext using transtext hash codes in msgid to retrieve msgstr. Whether interactive or all at the end before saving would be options . But I have been testing transtext with the 'interactive' popup on my script (3500 lines), and because I have many language code lists there are just so many one word popups to deal with, of course they timeout and accept status quo translations. So for all these options there would need to be either a config file to setup, or a config and initial gui to set preferred behaviour. To finish all of that requires more motivation than I presently have, as I have no sense of need for it. All in good time though.

d) Process translated .po file, updating '.transtext' files, where necessary.
If "msgstr" is "", write "\0".
Not interactive.

Scripts c) and d) should make currrent experienced translators feel more comfortable with transtext,
because they can do their normal thing, but instead of converting the final .po file to .mo file,
they run script d), without ever seeing an automatic translation.

This informs future development possibilities. However I have to reiterate a non-commitment on my part to code 'support' for the old method, which I cannot see being used on or as a transblockchain, with distributed translations all addressed with hashes ... that's the potential I see with transtext.

[stemsee]

I removed the 'en' test and decided even own language scripts get 'translated' into transtexts. It's better for providing language packs.

[gyrog]

If you need a .po file, you can download a real one form https://www.mediafire.com/file/4g96yycr ... 0.po/file .

[gyrog]

I might have a go at the translated .po extraction/update scripts when I return.

[gyrog]

There is probably no need to write the "\0" to the transtext file, just an empty string.
Although gettext() would still need to return "$1" if the retrieved value is empty.

After all, in transtext, a translation exists if a transtext file exists for the "msgid", no matter what the contents of that transtext file.
Translation is only performed/offered if no transtext file exists.

[stemsee]

The interactive transtext popup

xscreenshot-20230527T191803.png (28.89 KiB) Viewed 2099 times

[gyrog]

Starting to look like something.
I must admit that I thought that it would be simpler, i.e. just 2 panels, "original" and "translation".
With a "Save" button that saves whatever is in the "translation", even if that is empty.
But hey, it's your baby.

I don't like the dialog's "title" at all.

[stemsee]

That was an early version....just being lazy

xscreenshot-20230529T161814.png (40.5 KiB) Viewed 2090 times

[stemsee]

Here is a system script source code. published as transtext-0.1.tar.gz

transtext-0.1.tar.gz

(1.15 KiB) Downloaded 41 times

To operate in another language other than the system $LANG then the script requires the existence of the $lng variable set as the language code for
example German 'de', 'it' for Italian etc. Also set $alt_lng for a second translated language. Or change the system $LANG variable.

There is a transtext function in this script as the gui for editing is in the gettext function and must not call its own gettext function as it creates an infinite loop, so it calls transtext, and so should any other gui in the gettext function.

The script is named gettext and is in /usr/sbin ... backup the gettext binary or relocate this script preferably more forward in the system $PATH.

this does not include the 'trans' script.

[stemsee]

In the case where there is no internet, I added a simple ping test for the translate.google.com website, if not found then return original text string.

[stemsee]

Next step is to realise the possibility of audio labels in interfaces. Still using the same hash to pull up the audio from Google or locally stored. This only requires a per language directory. and audio subdirectory. Not requiring a separate text to audio program. Although with espeak installed text to audio would be readily available.

How to sound the selected labels, xdotool for cursor, and keybindings using xev maybe. Transtext might need a transtext-audio daemon.