Missing translations on UI

Hi,

I have tested the UI from v 4.0 (RC3) on Ubuntu and Windows I am noticed
about some lost in translation, here and there. Perhaps 7 ou 8 strings.

I suspect that It's common for all languages. I have checked galician
interface. I think that the exportación process from Pootle is the problem

For example in Standar bar, the unlocalizated opción is with *mark

File
     *Exit LibreOffice
View
     Zoom
            *Page Width
Insert
      Header
             *Default Style
      Footer
              *Default Style

      *Floating Frame

I do not have that problem with Slovenian, but I am using my own
translation system, not Pootle.

With so many recent reports of strings in Pootle not showing up to
translators during translation process should be a warning - this is
something that needs to be addressed IMHO.

Lp, m.

I Martin and all

The strings non translated in UI are, all of them, translated in Pootle.
So, isn't a problem about Pootle hiding the view for the translator; but as
you say, if for slovenian there is no problem, then I think the problem is
before the compiling process, perhaps in export from Pootle, at least for
some languages as galician.

In spanish this not happen.

For me, it's a blocker. We will have at least a RC4, isn't?

Hi, Anton!

I have tested the UI from v 4.0 (RC3) on Ubuntu and Windows I am noticed
about some lost in translation, here and there. Perhaps 7 ou 8 strings.

I suspect that It's common for all languages. I have checked galician
interface. I think that the exportación process from Pootle is the problem

For example in Standar bar, the unlocalizated opción is with *mark

File
      *Exit LibreOffice
View
      Zoom
             *Page Width
Insert
       Header
              *Default Style
       Footer
               *Default Style

       *Floating Frame

----
LibreOffice Options

     LibreOffice Writer
             General
                          Count words
                                   *Additional separators

Format

All these strings are translated in German. We use Pootle for translation, too, so it can't be a Pootle probleme.

I see therefor untranslated strings at:

Tools
       XML Filter settings...
                              *New...
                              *Edit...
                              *Text XSLTs...
                              *Delete...
                              *Save as Package...
                              *Open Package...
                              *(all filter names)

Can anybody confirm this for other languages?

Greetings,
Christian.

I confirm it, with LibO 4.0 RC3, Catalan, theses strings appear in English.

Joan Montané

Yes, I can confirm these still in English, even on the Slovenian build :slight_smile:
And it's not just these buttons, what about the "Name" column in the
same dialog - shouldn't the file types be translated as well?

A stopper, yes. If this was another "easy hack" coders that are
remodeling dialogs should be more careful or should have someone above
them checking that every transfer they make is a complete one. If this
will not be a stopper and if the review system for this kind of easy
hacks doesn't get sorted out we can be sure that these problems will
only grow with further transfer of dialogs to the new type - so for
4.1 etc. we will have many, many unlocalizable strings in the gui. And
they won't be a stopper. And it will look like we, the localizers,
were lazy. And such software will have a problem to be used/adopted in
public services in non-English communities.

Lp, m.

Hi Martin, all,

Yes, I can confirm these still in English, even on the Slovenian build :slight_smile:
And it's not just these buttons, what about the "Name" column in the
same dialog - shouldn't the file types be translated as well?

I sent a mail last week about it but it seems it get lost. The right way
to mention such bugs we see as a stopper would be to file an issue and
mention it on the dev list. I didn't do it.
In my own personal opinion on the FR version, this is not a blocker
because this version will not be recommended for production, not made
available for average users, only for advanced ones. I'm not happy to
see these strings when I've done my work, and I think this is something
that should be and can be solved.

A stopper, yes. If this was another "easy hack" coders that are
remodeling dialogs should be more careful or should have someone above
them checking that every transfer they make is a complete one. If this
will not be a stopper and if the review system for this kind of easy
hacks doesn't get sorted out we can be sure that these problems will
only grow with further transfer of dialogs to the new type - so for
4.1 etc. we will have many, many unlocalizable strings in the gui. And
they won't be a stopper. And it will look like we, the localizers,
were lazy. And such software will have a problem to be used/adopted in
public services in non-English communities.

So let sort the issue before 4.1. The 4.0 release will be announced
Thursday, it's a bit late to react now for this one.
Now, my opinion on this release cycle for l10n team:
- rc2 was announced the 25th, that was the only version containing the
full localization, freeze for rc3 was on the 28th --> only 3 days to
test everything and find/correct the bugs,
- rc3 was delayed and so we had even less time.

I think that we need more time to be able to check our translations and
solve where the issue is lying to be able to enhance our workflow.
I'm going to open the discussion with the developers on that topic.

To all, do you think that will help to solve our issue or is there
anything else we should discuss ?

Kind regards
Sophie

Hi,

Hi Martin, all,

Yes, I can confirm these still in English, even on the Slovenian build :slight_smile:
And it's not just these buttons, what about the "Name" column in the
same dialog - shouldn't the file types be translated as well?

I sent a mail last week about it but it seems it get lost. The right way
to mention such bugs we see as a stopper would be to file an issue and
mention it on the dev list. I didn't do it.
In my own personal opinion on the FR version, this is not a blocker
because this version will not be recommended for production, not made
available for average users, only for advanced ones. I'm not happy to
see these strings when I've done my work, and I think this is something
that should be and can be solved.

I agree that it is not a stopper. Unfortunately .0 releases are never
perfect. I'm sure we can fix this by 4.0.1, which is due to in 4
weeks.

First of all I need to investigate why it was happening in the first
place. Slovenian was affected, so we can rule out Pootle bugs. I'll
let you know when I find out something.

Thanks,
Andras

Andras et al.,

can you confirm that this is one of the products of this:
http://blogs.linux.ie/caolan/2013/01/24/converting-libreoffice-dialogs-to-ui-format-100-conversions-milestone/

If so, it seems that the project of this conversion is not totally
under control in regard to the localization issues - i.e. as we saw in
the preRC3 versions for 4.0, it happened before. If that is the case -
there must be some QA control added for every single dialog converted
that truly all strings were respected in the conversion. It is too
late to see in the release that there are 5 dialogs that were not
converted properly (if one of us happens to see it in the UI).

Lp, m.

Andras et al.,

can you confirm that this is one of the products of this:
http://blogs.linux.ie/caolan/2013/01/24/converting-libreoffice-dialogs-to-ui-format-100-conversions-milestone/

Yes, it was the case for the XML Filter Settings dialog. The fix is here
(target: 4.0.1): https://gerrit.libreoffice.org/#/c/2001/

If so, it seems that the project of this conversion is not totally
under control in regard to the localization issues - i.e. as we saw in
the preRC3 versions for 4.0, it happened before. If that is the case -
there must be some QA control added for every single dialog converted
that truly all strings were respected in the conversion. It is too
late to see in the release that there are 5 dialogs that were not
converted properly (if one of us happens to see it in the UI).

The bug in XML Filter Settings dialog has been there since Nov 16, 2012.
Nobody spotted it. This is not a dialog that we use every day, is it? If
you volunteer to QA commits that do this conversion, it is appreciated.
The commit message usually contains ".ui", so you can filter the commit
list. Also, the following command helps to find these problematic lines:

git grep '<property name="label">[_A-Z]'

Unfortunately I ran

git grep '<property name="label">[A-Z]'

before 4.0 RCs, so I did not find the cases when the word started with
an accelerator. Probably with these single command we could filter 99%
or even 100% of these type of bugs.

Best regards,
Andras

Hi Anton,

I checked the sourced of LibreOffice 4.0.0 RC3, and these strings were
not translated in Galician. I checked what I downloaded from Pootle on
2013-01-27, and these strings were not translated there, either. Now I
see that they are translated in Pootle. Did you translate them in
between?

Best regards,
Andras

Hi Andras,

Maybe, some strings I have finished between 27 - 30 of January.

In my tests over galician UI I saw some areas incomplete. For contrast, I
have checked the spanish UI but it is incomplete too. So, I don't know if
there is a especific problem or not. Is for that what I have questioned.
The Extensión Manager is not well translated in spanish but the options in
Standar Bar, yes. There must be some problem.

Thanx for your attention,

Cheers