See also bug 44762 (DataPilot naming of styles and request for more styles)

Thanks for bugreport
Please, attach document that demonstrates this problem

Created attachment 61716 [details]
Spreadsheet with a PivotTable, which was saved under english and german locale

(In reply to comment #2)
> Thanks for bugreport
> Please, attach document that demonstrates this problem

HTH

Thanks for attachment
Reproduced in 3.3.4 and 3.5.3 on Fedora 64 bit
Steps to reproduce:
0. Open attachment
1. Enable Stylist pane
Expected: All styles are with current UI language
Actually: One half is on German, other half on English
2. Modify some German named style, for example Datenpilot Titel, change cell background
3. Right click somewhere in the DataPilot and choose "Refresh" from the context
menu.
Expected: DataPilot formatting remains unchanged, no additional styles appear
Actually: DataPilot formatting lost, some additional styles appear

Changing version to 3.3.4 as most early reproducible

@ Andras
What do You think about this bug?

This has one gotcha.  First of all, I have these pivot table styles and I would LOVE to get rid of them.  But besides that, if we ever decide to keep them for the time being and decide to translate them, then we'd have to make sure that the implementation would continue to use the non-translated versions.  Or else it would break if the document is shared between different locales.

Regarding your new idea/proposal on pivottable design, I replied in the other bug 44762.

Regarding this one:
I don't quite get your comment:
(In reply to comment #6)
> But besides that, if we ever decide to keep them for the time being and decide
> to translate them, then we'd have to make sure that the implementation would
> continue to use the non-translated versions.
AFAIK, the style-names are already translated, as they are available in every locale.
Second, there is already an "engine" for style-translation which applies to all other styles (Default, Result, Heading, etc.).

So my question is, why is this "engine" not apllied to the pivot-table stles?
Wouldn't this be the simplest solution (for the time beeing)?


> ... Or else it would break if the document is shared between
> different locales
The current implementation *IS ALREADY* broken, when shared between different locales, so no worry about breaking things ;-) ...

(In reply to comment #7)
> Regarding your new idea/proposal on pivottable design, I replied in the
> other bug 44762.
> 
> Regarding this one:
> I don't quite get your comment:
> (In reply to comment #6)
> > But besides that, if we ever decide to keep them for the time being and decide
> > to translate them, then we'd have to make sure that the implementation would
> > continue to use the non-translated versions.
> AFAIK, the style-names are already translated, as they are available in
> every locale.
> Second, there is already an "engine" for style-translation which applies to
> all other styles (Default, Result, Heading, etc.).
> 
> So my question is, why is this "engine" not apllied to the pivot-table stles?
> Wouldn't this be the simplest solution (for the time beeing)?

You are asking the wrong guy.  I didn't design it, so no idea "why".  Maybe you can see if that's indeed the simplest solution.  Do you need a code pointer for this?

> > ... Or else it would break if the document is shared between
> > different locales
> The current implementation *IS ALREADY* broken, when shared between
> different locales, so no worry about breaking things ;-) ...

That's lame.  It's already broken, so who cares if you break a little more doesn't give me confidence.

(In reply to comment #8)

> > > ... Or else it would break if the document is shared between
> > > different locales
> > The current implementation *IS ALREADY* broken, when shared between
> > different locales, so no worry about breaking things ;-) ...
> 
> That's lame.  It's already broken, so who cares if you break a little more
> doesn't give me confidence.

And that's even another reason why we should get rid of this.  It's broken beyond repair.

(In reply to comment #8)
> (In reply to comment #7)
> > Second, there is already an "engine" for style-translation which applies to
> > all other styles (Default, Result, Heading, etc.).
> > 
> > So my question is, why is this "engine" not apllied to the pivot-table stles?
> > Wouldn't this be the simplest solution (for the time beeing)?
> 
> You are asking the wrong guy.  I didn't design it, so no idea "why".

You wrote: "I have these pivot table styles", so I thought you might know this. Also this was meant as a constructive question. I'm not trying to blame anyone for this history-grown code - sorry if it sounded otherwise.


> Do you need a code pointer for this?

I'm user doing some Q&A, I have no experience whatsoever with the LO-code. However if you think it is worth/promising to try - sure go ahead.
Another option might be to name me the "right" guy (if you know) and I will try to contact & point him to this bug. Maybe he can give some useful insights.


> > The current implementation *IS ALREADY* broken, when shared between
> > different locales, so no worry about breaking things ;-) ...
> 
> That's lame.  It's already broken, so who cares if you break a little more
> doesn't give me confidence.

Judging from your comment #6 one could get the impression, that by trying to fix this, things might broke which worked before. I just wanted to clarify this, also notice the smiley.

(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Second, there is already an "engine" for style-translation which applies to
> > > all other styles (Default, Result, Heading, etc.).
> > > 
> > > So my question is, why is this "engine" not apllied to the pivot-table stles?
> > > Wouldn't this be the simplest solution (for the time beeing)?
> > 
> > You are asking the wrong guy.  I didn't design it, so no idea "why".
> 
> You wrote: "I have these pivot table styles", 

That's a typo. I HATE is what I meant to type.

> Judging from your comment #6 one could get the impression, that by trying to
> fix this, things might broke which worked before.

Yes. You could say that.

In short, 

1) This mis-feature is broken by design, and as it stands today, it already causes issues in several areas which cannot be fixed without removing this mis-feature.
2) No point improving it because of 1).

If I can expand on this a little.

In the future we should remove this and implement much more flexible custom cell properties inside pivot table, combined with some sort of predefined styles that can be applied per table.  The current system allows uniform styles to ALL tables, which isn't extensible, conflicts with these new proposed features, not to mention it causes severe interop problems.

Hi.
I confirm that this bug is still present on Versión: LO 5.0.2.2
Id. de compilación: 37b43f919e4de5eeaca9b9755ed688758a8251fe
Configuración regional: es-MX (es_MX)on Win 10

I was going to file a bug about this, but found this one that is exactly what I am experiencing.

I'm adding screenshoots and a test file. 
This bug is reproducible changing the user interface form English to Spanish or Spanish to English.

After changing the user interface and opening the file, the pivot table is not refreshed and the filter drop down menu is not activated, this is related to te bug 84425, after clicking in the category field, the pivot table is refreshed, new styles appear and the formatting changes.

Created attachment 119265 [details]
Pivot Table test file

Created attachment 119267 [details]
Step 1 screenshoot

Created attachment 119268 [details]
step 2 screenshoot

Created attachment 119269 [details]
Step 3 screenshoot

Created attachment 119270 [details]
Step 4 screenshoot

Created attachment 119271 [details]
step 5 screenshoot

Created attachment 119272 [details]
Test Pivot table ES to EN

I've tested it on OOO 3.2.1 and the problem is present and reproducible, also tested it in A00 4.1.1 and is alo present and reproducible.

Ah well, why should one try to make sure the summary reflects the bug ? :\

*** Bug 113484 has been marked as a duplicate of this bug. ***

Tested with Version: 7.1.1.2 / LibreOffice Community
Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: kf5
Locale: es-MX (es_MX.UTF-8); UI: es-ES
Calc: threaded

The first thing I did was create a new file and copy the raw data from the 2015 test file with the Spanish UI.

Then I made a new pivot table to review the styles.

I modified the background color of the pivot table styles, to see if those properties were lost, when changing the UI. I saved the file.

I changed the UI to English and restarted LibreOffice, reloaded the file and noticed that the colors were kept and the styles were renamed to their respective English without affecting the pivot table. I saved the file.

I changed the UI back to Spanish and opened the file again and there were no impacts. The styles had their respective names in Spanish.

From the above, I could say that this bug is already resolved, however, I decided to review the 2015 test file.

When testing with the original test file from 2015, with the UI in Spanish, the pivot table styles were linked to the English names Data Pilot XXX and there were also the names in Spanish.

DataPilot Category
DataPilot Corner
DataPilot Field
DataPilot Result
DataPilot Title
DataPilot Value

I modified the styles to add background color to them and saved the file.
I changed the UI to English and opened the file, the colors remained intact.
When reviewing the styles were the above and the following:

Pivot Table Category
Pivot Table Corner
Pivot Table Field
Pivot Table Result
Pivot Table Title
Pivot Table Value

I opened the properties of the pivot table and clicked OK and the styles were updated to "Pivot Table XXXX" losing color.

Again I modified the styles to add background color to them, saved the file and changed UI to Spanish.

I opened the file again and the styles were updated to Spanish without affecting the pivot table. The previous “DataPilot XXX” styles were still there, but no longer assigned.

I removed them without affecting the file.

From the above, I could say that this bug is already solved, however, all tables created with previous versions must be updated.

I do not update the status, for someone else to test and verify it.