Question about Pootle

Hi all,
I have a small question about the merged files on Pootle. We can see
that there is a lot of strings with the a warning (Failing Checks) about
xmltags.

https://translations.documentfoundation.org/da/libo33x_help/translate.html?matchnames=xmltags

Does this indicate a problem or just that the check has failed? As far
as I can see there is no problem with most of these strings.

Cheers,
Leif Lodahl

2011.02.20 11:40, leif rašė:

Hi all,
I have a small question about the merged files on Pootle. We can see
that there is a lot of strings with the a warning (Failing Checks) about
xmltags.

https://translations.documentfoundation.org/da/libo33x_help/translate.html?matchnames=xmltags

Does this indicate a problem or just that the check has failed? As far
as I can see there is no problem with most of these strings.

It looks like the reason behind that is that you change the name= attribute of those tags. However, I'm not sure if that's bad for us or not. :slight_smile:

Maybe Sophie or someone else can tell more?

Rimas

Not more, just I agree :slight_smile: The guide says that we are allowed to translate them, page 12 you find:

Den 20-02-2011 11:11, Sophie Gautier skrev:

2011.02.20 11:40, leif rašė:

Hi all,
I have a small question about the merged files on Pootle. We can see
that there is a lot of strings with the a warning (Failing Checks)
about
xmltags.

https://translations.documentfoundation.org/da/libo33x_help/translate.html?matchnames=xmltags

Does this indicate a problem or just that the check has failed? As far
as I can see there is no problem with most of these strings.

It looks like the reason behind that is that you change the name=
attribute of those tags. However, I'm not sure if that's bad for us or
not. :slight_smile:

Maybe Sophie or someone else can tell more?

Not more, just I agree :slight_smile: The guide says that we are allowed to
translate them, page 12 you find:
---------------------------------------------
Element: link
Attributes: href, name, type, target
Description: Designates a hyperlink to another help file or to the WWW
as specified by the href attribute.
Element link
Rule: - Localize element content
    - Localize the name attribute
    - Copy the rest of the element tags exactly
Example:
Source:
\<link href=\"text/swriter/123.xhp\" name=\"Name of the
link\"\>Using Headings\<\/item\>
Localized:
\<link href=\"text/swriter/123.xhp\" name=\"Name des
Links\"\>Überschriften verwenden\<\/item\>
------------------------------------------
So, if you are sure that you didn't forget any part of the link, you
can simply ignore it.

Kind regards
Sophie

Thanks a lot Sophie :slight_smile:

Cheers,
Leif

Den 20-02-2011 11:11, Sophie Gautier skrev:

2011.02.20 11:40, leif rašė:

Hi all,
I have a small question about the merged files on Pootle. We can see
that there is a lot of strings with the a warning (Failing Checks)
about
xmltags.

https://translations.documentfoundation.org/da/libo33x_help/translate.html?matchnames=xmltags

Does this indicate a problem or just that the check has failed? As far
as I can see there is no problem with most of these strings.

It looks like the reason behind that is that you change the name=
attribute of those tags. However, I'm not sure if that's bad for us or
not. :slight_smile:

Maybe Sophie or someone else can tell more?

Not more, just I agree :slight_smile: The guide says that we are allowed to
translate them, page 12 you find:
---------------------------------------------
Element: link
Attributes: href, name, type, target
Description: Designates a hyperlink to another help file or to the WWW
as specified by the href attribute.
Element link
Rule: - Localize element content
    - Localize the name attribute
    - Copy the rest of the element tags exactly
Example:
Source:
\<link href=\"text/swriter/123.xhp\" name=\"Name of the
link\"\>Using Headings\<\/item\>
Localized:
\<link href=\"text/swriter/123.xhp\" name=\"Name des
Links\"\>Überschriften verwenden\<\/item\>
------------------------------------------
So, if you are sure that you didn't forget any part of the link, you
can simply ignore it.

Kind regards
Sophie

Again Sophie, Thanks a lot.
You are talking about "the guide". Where is that guide to be found?

/Leif

I guess false error detection should be removed then.

Lp, m.

Hi Leif,
[...]

Again Sophie, Thanks a lot.

You're welcome :slight_smile:

You are talking about "the guide". Where is that guide to be found?

Well in should be on the wiki under the Tips/tricks and tools of that page:
http://wiki.documentfoundation.org/Language

But I didn't have the time yet to finish the pages. I thought that all the teams get it already too :slight_smile: I'm attaching it, hope it won't be removed. I'll add it to the wiki asap.

Kind regards
Sophie

There was some discussion about this over at OOo. Seems that the entries when used are case insensitive, but of course our tests aren't. One of their solution was the idea of normalising all these entries.

I'm not sure we want to change the xmltags test in this case but rather fix this in the source and target text.

regards
Dwayne

Hi Dwayne,

2011.02.20 18:40, Dwayne Bailey rašė:

2011.02.20 11:40, leif rašė:

Hi all,
I have a small question about the merged files on Pootle. We can see
that there is a lot of strings with the a warning (Failing Checks) about
xmltags.

https://translations.documentfoundation.org/da/libo33x_help/translate.html?matchnames=xmltags

Does this indicate a problem or just that the check has failed? As far
as I can see there is no problem with most of these strings.

It looks like the reason behind that is that you change the name= attribute of those tags. However, I'm not sure if that's bad for us or not. :slight_smile:

Maybe Sophie or someone else can tell more?

There was some discussion about this over at OOo. Seems that the entries when used are case insensitive, but of course our tests aren't. One of their solution was the idea of normalising all these entries.

I'm not sure we want to change the xmltags test in this case but rather fix this in the source and target text.

Well in https://translations.documentfoundation.org/da/libo33x_help/translate.html?matchnames=xmltags, I don't see case differences, but the string is still reported.

Rimas

Translate Toolkit defines canchangetags for openoffice as link and name, so it should be passing. Is this project setup for openoffice checks instead of the default?

Hi,

Von: Dwayne Bailey <dwayne@translate.org.za>

> Well in
>
https://translations.documentfoundation.org/da/libo33x_help/translate.html?matchnames=xmltags,
> I don't see case differences, but the string is still reported.
Translate Toolkit defines canchangetags for openoffice as link and name,

means change in link (href) or name values would be allowed and not reportet
as error?

so it should be passing. Is this project setup for openoffice checks
instead of the default?

It's set to openoffice.

regards,

André

2011.02.22 10:21, Dwayne Bailey rašė:

Hi Dwayne,

2011.02.20 18:40, Dwayne Bailey rašė:

2011.02.20 11:40, leif rašė:

Hi all,
I have a small question about the merged files on Pootle. We can see
that there is a lot of strings with the a warning (Failing Checks) about
xmltags.

https://translations.documentfoundation.org/da/libo33x_help/translate.html?matchnames=xmltags

Does this indicate a problem or just that the check has failed? As far
as I can see there is no problem with most of these strings.

It looks like the reason behind that is that you change the name= attribute of those tags. However, I'm not sure if that's bad for us or not. :slight_smile:

Maybe Sophie or someone else can tell more?

There was some discussion about this over at OOo. Seems that the entries when used are case insensitive, but of course our tests aren't. One of their solution was the idea of normalising all these entries.

I'm not sure we want to change the xmltags test in this case but rather fix this in the source and target text.

Well in https://translations.documentfoundation.org/da/libo33x_help/translate.html?matchnames=xmltags, I don't see case differences, but the string is still reported.

Translate Toolkit defines canchangetags for openoffice as link and name, so it should be passing. Is this project setup for openoffice checks instead of the default?

Ah, I've changed the values in project setup, but still the same strings are reported as not passing xmltags. Is there anything else I should do?

Rimas

Hi,

Von: Dwayne Bailey<dwayne@translate.org.za>

Well in

https://translations.documentfoundation.org/da/libo33x_help/translate.html?matchnames=xmltags,

I don't see case differences, but the string is still reported.

Translate Toolkit defines canchangetags for openoffice as link and name,

means change in link (href) or name values would be allowed and not reportet
as error?

link="something" -> link="anotherthing"
name="Name" -> name="Naam"

Should not report errors

href="one" -> href="two"

Should report an error

I've just put this in the Translate Toolkit test harness and it passes.

Since the project values changes can you run refresh_stats against the project and Danish to confirm? IF that works then you'll need to run it against the whole project.

2011.02.28 11:28, Dwayne Bailey rašė:

2011.02.22 10:21, Dwayne Bailey rašė:

Translate Toolkit defines canchangetags for openoffice as link and name, so it should be passing. Is this project setup for openoffice checks instead of the default?

Ah, I've changed the values in project setup, but still the same strings are reported as not passing xmltags. Is there anything else I should do?

I've just put this in the Translate Toolkit test harness and it passes.

Since the project values changes can you run refresh_stats against the project and Danish to confirm? IF that works then you'll need to run it against the whole project.

I've ran it for all three projects/all languages, and the result is still the same...

Rimas

Looks like a bug.

There are some other things we could try:

1) sync_stores, move files to a temporary dir, update_stores to reset everything
2) Move files back and update_stores to restore everything

Its probably best to continue this conversation on the Pootle mailing list.

Hi Dwayne,

2011.03.01 10:23, Dwayne Bailey rašė:

2011.02.28 11:28, Dwayne Bailey rašė:

2011.02.22 10:21, Dwayne Bailey rašė:

Translate Toolkit defines canchangetags for openoffice as link and
name, so it should be passing. Is this project setup for
openoffice checks instead of the default?

Ah, I've changed the values in project setup, but still the same
strings are reported as not passing xmltags. Is there anything else
I should do?

I've just put this in the Translate Toolkit test harness and it passes.

Since the project values changes can you run refresh_stats against
the project and Danish to confirm? IF that works then you'll need
to run it against the whole project.

I've ran it for all three projects/all languages, and the result is
still the same...

Looks like a bug.

There are some other things we could try:

1) sync_stores, move files to a temporary dir, update_stores to reset
everything
2) Move files back and update_stores to restore everything

Its probably best to continue this conversation on the Pootle mailing
list.

This worked! Well, except a problem with Luxembourgish that I mentioned
on IRC, which I worked around later by repeating the steps for this
language only. Thanks!

Rimas

Excellent. Could you report a bug at bugs.locamotion.org please.

Hi Dwayne,

2011.03.03 07:32, Dwayne Bailey rašė:

2011.03.01 10:23, Dwayne Bailey rašė:

Looks like a bug.

There are some other things we could try:

1) sync_stores, move files to a temporary dir, update_stores to reset
everything
2) Move files back and update_stores to restore everything

Its probably best to continue this conversation on the Pootle mailing
list.

This worked! Well, except a problem with Luxembourgish that I mentioned
on IRC, which I worked around later by repeating the steps for this
language only. Thanks!

Excellent. Could you report a bug at bugs.locamotion.org please.

I don't think we have clear steps to reproduce this, so I'm reluctant to file this bug... :expressionless:

Rimas