Translations from Pootle pushed to git (for 3.4 beta2), bugs to fix

l10n
#21

2011.04.20. 5:34 keltezéssel, Sophie Gautier írta:

But thanks a lot again really, that will help me to correct the files
quickly later today.

I fixed all build build breakers in cy, fr, ja and pt in git. Next time
I'll check them before I commit.

Best regards,
Andras

#22

You could try these two suggestions:

1) Run 'po2oo --filteraction=warn' or 'pofilter --openoffice'. Either will pick up your errors before needing to run gsicheck. If you get stuck I can give lessons. Both of these will use the same checks that are available on Pootle.

2) Try Virtaal beta5 - this includes the LibO specific checks as you type. Installation instructions:
Win: http://translate.sourceforge.net/snapshots/virtaal-0.7.0-beta5/Virtaal-0.7.0-beta5-setup.exe
Debian: http://markmail.org/message/s35zfyofrc3qad2v
Fedora: http://markmail.org/message/2wpzjejxgauz5f4k

#23

Hi Andras

In pt I fixed the lines in
http://ftp.fsf.hu/LibreOffice/3.4-beta2-l10nbugs/pt.err but I cant find the
file that has double entry reported in
http://ftp.fsf.hu/LibreOffice/3.4-beta2-l10nbugs/pt.log

Entry double for LANG=pt in file pt.sdf

sw source\ui\utlui\poolfmt.src 0 string STR_POOLCOLL_HEADLINE_BASE 0 pt Cabeçalho 2002-02-02
02:02:02
sw source\ui\utlui\poolfmt.src 0 string STR_POOLCOLL_HEADER 0 pt Cabeçalho 2002-02-02
02:02:02

Can You point me the way?

Regards

#24

Hi *,

[broken translations that break the build]
So please fix those "Expected Symbol: Close tag for<tagname>" ones as
fast as possible, and have Andras upload them, otherwise chances are
that your language will just be skipped.

For your convenience, I wrote a awk one-liner to turn the error-log
into clickable URLs that will take you to the translation unit in
question:

Nice. Could we put an HTML page based on your awk script up to complement the raw data? This certainly makes finding and fixing the errors easy.

#25

Hi Sérgio, *,

Hi Andras

In pt I fixed the lines in
http://ftp.fsf.hu/LibreOffice/3.4-beta2-l10nbugs/pt.err but I cant find the
file that has double entry reported in
http://ftp.fsf.hu/LibreOffice/3.4-beta2-l10nbugs/pt.log

Entry double for LANG=pt in file pt.sdf

sw      source\ui\utlui\poolfmt.src     0       string  STR_POOLCOLL_HEADLINE_BASE                              0       pt      Cabeçalho                              2002-02-02

https://translations.documentfoundation.org/pt_BR/libo34x_ui/sw/source/ui/utlui.po/translate/?search=STR_POOLCOLL_HEADLINE_BASE&sfields=locations
(https://translations.documentfoundation.org/pt_BR/libo34x_ui/sw/source/ui/utlui.po/translate/?unit=3495718)

02:02:02
sw      source\ui\utlui\poolfmt.src     0       string  STR_POOLCOLL_HEADER                             0       pt      Cabeçalho                              2002-02-02
02:02:02

https://translations.documentfoundation.org/pt_BR/libo34x_ui/sw/source/ui/utlui.po/translate/?search=STR_POOLCOLL_HEADER&sfields=locations

(https://translations.documentfoundation.org/pt_BR/libo34x_ui/sw/source/ui/utlui.po/translate/?unit=3495837)

ciao
Christian

#26

Thanks Christian,

Your information was relevant.

regards

#27

Hi again,

Your information was relevant.

Hmm - your fix seems suboptimal.

the HEADING one is the paragraph style entries in Format & Styles, you got
Heading
Heading 1
Heading 2
...
Heading 10

i.e. those are the styles to structure and format your documents.

You did choose
Cabeçalho principal
Cabeçalho 1
...
Cabeçalho 10

I think this is misleading, as the "Heading" style is not meant for
structuring, but to define basic styling (Font, ....) for all the
other headers, instead of setting this for each Header 1-10 manually.
(i.e. you're not supposed to apply that style to your document, but
only use the numbered ones, the one without number is only to define
common formatting)

The HEADER one on the other hand has nothing to do with
heading-styles, but it is the one meant for the area on top of each
page, that is the same on all pages (the thing at the bottom is the
footer), you set it in Format|Page
As there are left and right pages, there is the base Header style and
also Header left and Header right.

Of course I don't really know Portuguese, but having the same word for
both sounds really strange to me (and the pt_BR variant uses Titulo
for the Heading ones)

ciao
Christian

#28

Hi Christian

thanks for You explanation.

you are correct. I will correct all strings with "Heading" word

#29

Also, same word in English may indeed relate to a different words in translation depending on context.

-Yury

...

#30

Hi Dwayne, *,

So now there are 3 checks in place for translations:
gsicheck - standard check for tags etc.

This should be integrated into pootle somehow - and errors in there
should "block" the exporting (syncing to on-disk-files) to avoid
checking in invalid files (that then break the build)

The problem is false positives. So I'm a bit reluctant to make it blocking. Its also a bit confusing to a user who then can't work out why their changes aren't on disk.

What probably should be done is to use po2oo with validation enabled. We coded it a while back and I don't think anyone is using it. This can either warn or drop translations that are failing, we only do it on critical tests: variables, escapes IIRC. This could be enabled to drop in early phases and then warn towards the final release.

readmecheck - same as gsicheck but for the readme
doublecheck - check if different English strings were translated into
the same at critical parts of the code

In an ideal world I'd love those tools to inject the found errors back into
Pootle so that you have one place to find and fix errors and no cryptic
strings we need to search for.

Yes, indeed. But pootle should be more strict than gsicheck (but of
course it should cover everything that gsicheck finds) While pootle
already catches some of the errors, it doesn't flag this one for
example:

We designed it to catch all gischecks and more, so yes please report ones that we miss. The idea being that it's easier to fix these errors in Pootle then to try and 1) understand the gsicheck failure and 2) find the errors in Pootle.

https://translations.documentfoundation.org/fr/libo34x_help/shared/00.po/translate/?sfields=locations&search=par_id3149902.25

(in case sophie is too fast and fixes it in the meantime:
<variable id="FehlendesElement">Dans une fenêtre de fichier de base
de données, cliquez sur l'icône<emph>Requêtes</emph>, puis choisissez
<emph>Éditer - Éditer</emp>. Lorsque les champs de référence
n'existent plus, vous voyez cette boîte de dialogue</variable>

i.e.
<variable>
  <emph></emph>
  <emph></emp> !!!! non-matching - missing "h" - pootle doesn't flag it
</variable>

I've created http://bugs.locamotion.org/show_bug.cgi?id=1910

It's always better to have some false positives than to miss stuff.

Except when we have too many false positives of course :slight_smile: Now that we can mark false positives it makes it a bit easier to eliminate those.

And may I suggest to change the theme to give a bigger font for the
translation-box? I guess that's one of the reasons of missing quotes
or writing an *opening* tag as</tag> and not noticing it.

You'll have to fight with Friedel on that one. These are in CSS so you can change that on the LibO server.

But even better would be a "commit-hook" that instead of letting you
advance to the next translation unit points you back at the
just-changed string with a message "You very likely introduce an error
here - you mistyped the tag's name or something" :slight_smile:

Or something like that. I'd prefer live, but that involves AJAXy stuff and probably better suited for Pootle 2.2. I have some other ideas that could be quick wins and work on 2.1.x.

#31

Seems that we do detect this error correctly.

My guess is that it was marked as a false positive. We should be seeing puncspacing and doublespacing errors on this one and we're seeing no errors.

#32

Dear Christian,

That's a very strange attitude. So you're telling Slovenian users to
screw themselves

as the sole localizer of OpenOffice.org/LibreOffice versions from 3.0 on I
am the last person that could be labeled with such blatant words.

I do not want to step up to your level of communication so I will just stop
at that.

Lp, m.

#33

O , 2011-04-19 23:34 +0200, Martin Srebotnjak rakstīja:

I don't care what your script says but for Slovenian this is not an
error -
it would be an error if those strings had a different translation.

The point is, translating those two strings the same results in lost
styles at best, and broken documents at worst. In Latvian there is
exactly the same problem, the workaround is that "Title" becomes
"Document title" and "Subtitle" — "Document subtitle". It is ugly, but
it is also a bug.

#34

Is this string correct? Is very strange

[file]
LibreOffice 3.4.x – UI » instsetoo_native / inc_openoffice / windows /
msi_languages.po

[ref]
Control.ulf#OOO_CONTROL_206.LngText.text

[string]

error text goes here error text goes here error text goes here error
text goes here error text goes here error text goes here error text
goes here error text goes here error text goes here error text goes
here

#35

This is some dummy text. Don't worry about it. Leave it in English.
Maybe the error text really goes to the buffer that is allocated by
this string...

Best regards,
Andras

#36

Thanks Andras, I was getting a bit confused as I could not find the errors for the cy translation in the log... :wink:

#37

Hi Dwayne, all!

We already do this kind of adaptation for French guillemets so we could
probably easily adapt it for Hungarian. So yes that is the type of
false positive I'm interested in hearing about and fixing.

If you can give more examples of those strings so that I can build tests
that would be helpful,

For Asturian language (and Spanish, Galician and Catalan, at least)
'startpunct' throws false positives because of the required characters
"¿" and "¡" (inverse quotation and exclamation marks). It would be great
to have it fixed in Pootle.

French guillemets adaptation would be also useful for us.

Best regards,