Looking at Rosetta, i can see that some people have been working on translations recently. I don't know when was the last sinc and how many of these work should be "discard" if we cannot import as we expect. Anyway, the best choice is get the work done there imported and updated; and then use whatever (qtlinguistic or kbabel, that if i'm not wrong deal with a ts file).

Dave and someone who has blogs for nerds, could you please ask for a solution. (Dave told about it recently, but haven't asked for ideas). Something like:
------
Dear lazyweb.
We have a po file, and we need to merge it back to a ts file. (etc, etc, etc.)
------

It is easy (and fast) to get the po file from lauchpad.

Well, that all!


Dave Neary escreveu:
Hi,

Claudio André wrote:
Since we might need to deal with ts files, i was trying to update the
pt_BR translation from po file.

The way the ts file should be: (note the file name and line number)
    <message>
        <location filename="../imaccount/AIMSettings.ui" line="16"/>
        <source>AIM/ICQ Settings</source>
        <translation>Paramètres AIM/ICQ</translation>
    </message>

If i convert the po file to ts file using po2ts, i'm not going to have
these information:
        <message>
            <source>
                AIM/ICQ Settings
            </source>
            <translation>
                Configurações do AIM/ICQ
            </translation>
        </message>

...

In the wiki, i only found information about the translation toolkit
(ts2po). Anyone can give me more information? Is there a merge somewhere?

I've spent the morning figuring out the problems here.

There is the one Claudio mentions. ts2po then po2ts is a lossy
operation, we lose reference strings - in fact ts2po doesn't add them to
the .po file at all.

For information, a .po file entry typically looks like this (from a file
I have hanging around here):

#: src/options_menu.cpp:49
#: src/game_session.cpp:104
#: src/title.cpp:275
#: src/worldmap/worldmap.cpp:148
msgid "Options"
msgstr "Nastavení"

The lines starting # are comments, indicating cross-references in the
source code.

These lines don't get added to a .po file generated by ts2po.

There is a second problem (quite serious too, and since it's a problem
with the tool, not easy for us to fix). We generate lots of duplicate IDs.

In my opinion, the blank msgids can be eliminated quite easily - I
looked at a couple, and they were labels on form elements where there
will also be an image, like an alt attribute. Se we just need to set the
string, and we're done.

But I did an investigation of the other msgids:
[EMAIL PROTECTED]:~/src/wengophone-2.1/wengophone/src/presentation/qt/lang$
grep '^msgid' qtwengophone.pot | sort | uniq -c | sort -rn | head -20
     30 msgid ""
     14 msgid "Cancel"
      7 msgid "Password:"
      6 msgid "Login:"
      6 msgid "Form"
      5 msgid "Status"
      5 msgid "Close"
      5 msgid "Add"
      4 msgid "&Yes"
      4 msgid "WengoPhone"
      4 msgid "Save"
      4 msgid "&No"
      4 msgid "Language"
      4 msgid "General"
      4 msgid "Call"
      4 msgid "Audio Codec"
      3 msgid "Video"
      3 msgid "Online"
      3 msgid "OK"
      3 msgid "Notifications & Sounds"

In fact, we have 82 duplicate msgids other than "".

The problem is that in .po files, all the msgids are assumed to have the
same translation - and they must all be grouped together. For oo2po and
other filters in the language-tools package, there is the option to
group duplicates, this option doesn't appear to be supported for ts2po.

So - what do we do? There is both the short term and long term problem.
We need a way to offer translations in the 2.1 release, and that means
having a way to let translators get at the strings.

Short-term, we can encourage people to use qtlinguist for this release.
We can massage the .po files. We can try to fix the problems in ts2po.

Long term, we can study a move to gettext (which is what KDE uses). We
can try to get these issues in the language tools addressed & fixed. We
should integrate msgfmt into the export process to Launchpad if we
continue using it. We can try poodle.

I'm open to suggestions, and as release manager, Jérôme will have the
final say.

Cheers,
Dave.


_______________________________________________
Wengophone-devel mailing list
[email protected]
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Reply via email to