Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: DAViCal: Dev

[DAViCal-general] Question about internationalization

 

 

DAViCal dev RSS feed   Index | Next | Previous | View Threaded


andrew at morphoss

Oct 22, 2009, 10:28 PM

Post #1 of 2 (254 views)
Permalink
[DAViCal-general] Question about internationalization

On Thu, 2009-10-22 at 16:40 +0200, Matthias Mohr wrote:
> Hi Andrew,
>
> there are a lot of strings in the GUI which are still not translated - or to clarify things,
> sometimes they have a proper translation in the .po file, but it still does not get translated.
>
> So I tried to find out what's going on - and don't understand it.
>
> I added a line in the translate function which prints out a debug message when the translated string is the same as the input
> string:
> (Translation.php, line 66ff):
> -------------------------------------------------------------------------------------------------------------------------------
> function translate( $en ) {
> $xl = gettext($en);
> dbg_error_log("I18N","Translated =%s= into =%s=", $en, $xl );
> if ( strcmp($xl, $en) == 0 ) {
> $curlocale = setlocale( LC_ALL, 0 );
> dbg_error_log("I18N","Translation of =%s= not available (locale=%s)!", $en, $curlocale );
> }
> return $xl;
> }
> -------------------------------------------------------------------------------------------------------------------------------
> BTW, when I try to print out "$c->current_locale" instead of the return value of "setlocale" above,
> it always prints an empty string.
> Why? awl_set_locale (which sets that variable) has been called???

For that to work you need to add:
globals $c;
at the start of the function :-)


> After adding the above lines I identified a lot of strings which apparently seems to miss translation.
> I picked up one string ("User Name") which is often used and does not get translated.
> I then looked at "de.po" (which is used in my case) for the msgid and found the following:
> -------------------------------------------------------------------------------------------------------------------------------
> #~ msgid "User Name"
> #~ msgstr "Benutzername"
> -------------------------------------------------------------------------------------------------------------------------------
> So as you can see, the translation is present, but commented out.
> Then I decided to remove the "#~ " at the beginning of that line to uncomment the lines.
>
> After that I run a "make built-po" in the base directory.
> When I open the de.po after that call, the above two lines are commented out again!
> Why?

The de.po file is merged from the po/messages.pot which is in turn built
from the po/strings.raw file. This process is done by the scripts in
scripts/po which parse the source code looking for strings that will
need translating (i.e. scripts/po/extract.pl) to write strings.raw and
then various gettext tools build the po/messages.pot file from this.

It's all scripted by scripts/po/rebuild-translations.sh and there may
well be some flaw in the process.


> What am I missing? Is the make call mentioned aboce correct?
> Could you please explain the whole translation mechanism a bit?

Supposedly this is all standard gettext stuff, but while I felt
user-interface translation was an important thing to have in DAViCal, it
(inevitably) isn't important to the primary developer...

I would love it if you can review the process and find out what, if
anything, is going wrong.


> BTW, the output of the above debug lines is absolutely confusing - it tries to translate all my usernames and other stuff (e.g.
> already translated strings).
> I'm sure there's potential for further improvements ;-)

I'm sure there is too. Lots :-)

I only natively speak English. While I spoke some French as a kid, and
some German as a university student those days are long behind me and I
remember little of them. Currently the best I can muster for a second
language is a smattering of traveller's Spanish - enough to order food,
accommodation and travel, but still not enough to hold a conversation.
These give me a small understanding of the problems of translation, but
I'd be happy to be more educated.

Cheers,
Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Q: What do they call the alphabet in Arkansas?
A: The impossible dream.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20091023/4a2a49e2/attachment.pgp>


andrew at morphoss

Oct 23, 2009, 1:26 AM

Post #2 of 2 (238 views)
Permalink
[DAViCal-general] Question about internationalization [In reply to]

On Thu, 2009-10-22 at 18:06 +0200, Matthias Mohr wrote:
> Hi Andrew,
>
> Now I found out what was missing at my setup.
> My libawl directory is not reachable as "../awl" so the
> "rebuild-translations.sh" script was not able to detect the strings of
> the awl library.
> As a consequence all libawl-messages in my last contributed "de.po"
> have been commented out :-(

Thanks for spotting that. I've added a test now that if it can't find
it in ../awl it looks in /usr/share/awl and if it can't see it there it
quits with a hopefully informative error message.


> Now I set a symbolic link to my real libawl directory and things go much better now...
>
> Please find a better and more complete version of my "de.po" as
> attachment to this mail.

Applied. Thanks.


> I still get strings which are not translated, but these are not as
> many as earlier...
>
> What I still get are the attempts to translate already translated
> strings and to translate my usernames...
> Which is a bit odd ;-)

There are some circumstances where the translations are somewhat blind
attempts to translate values that came out of the database, but I didn't
think it extended to usernames. Relationship names, sure, but
usernames? That's odd.


> A short explanation about when to use the "i18n" method instead of
> "translate" and how the complete language cylce works would still
> be really appreciated...

i18n() marks the string as something that is known that this string
needs to be able to be translated, but the actual place where the string
occurs is not where the translation occurs. translate() actually does
the translation. In fact i81n() is a runtime noop which is discovered
by extract.pl, so the string is included.

An example, is when you have many strings assigned in a case statement,
but only one of them is actually printed. It is important that they all
be translated, but since only one will actually appear on the screen
it's silly to do the actual string conversion on all of them, so we use
i18n() inside the case statement where the assignment occurs, and
translate($variable) at the point where we print it.


> BTW, the URL to the Wiki-Translation page in the comments of the
> "i18n" method in "Translations.php" is wrong - it still contains
> "RSCDS" instead of "DAViCal"...

Man, that name is hard to kill - in fact I can't find the place you
reference there... though I found some others :-)

Can you reference file/line?

Cheers,
Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You will feel hungry again in another hour.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20091023/f4fafddb/attachment.pgp>

DAViCal dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.