Description: Documents using several languages is nothing special. For example you send new years greetings in your local language and in English. Assume the case you are writing a letter. You add a date field to get e.g. "December, 31, 2020". For the second language, you need the date field to output e.g. the German "31. Dezember 2020". The intuitive way is to highlight the fields and its surrounding text and set the language to German. But thus does not affect the date field. It cost me a lot of time and first with the help in bug #139288 I was able to get the language for the field as well. I don't know if it is a bug that the fields don't change the language the "normal way" or a missing feature. Steps to Reproduce: 1. Insert a date field 2. Select it and apply the language you like to it Actual Results: the date field still shows English day and month names. Expected Results: the date field will contain the day and month names of the applied language. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.1 (x64) Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4 CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded
Created attachment 168696 [details] Screencast of changing date field's surrounding text language Cannot repro with Version: 7.1.0.1 (x64) Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4 CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
> Cannot repro with Version: 7.1.0.1 (x64) That' interesting because I found out that with LO 7.0.4 it works, see attached the screencast. But with LO 7.1RC1 is does not work. I will investigate further and report back.
Created attachment 168703 [details] screenshot that it works with LO 7.0.4
Created attachment 168704 [details] testcase that works
(In reply to muso from comment #2) > > Cannot repro with Version: 7.1.0.1 (x64) > > That' interesting because I found out that with LO 7.0.4 it works, see > attached the screencast. > But with LO 7.1RC1 is does not work. It may depends on details of local installation, locales, which language support components are installed, etc. In my case, Chinese Windows with LO 7.0.4, English UI [1], there is no German option in the choice of languages, either from the status bar or Tools > Languages menu. But if I go through a rather long (and IMHO not very intuitive) process of: 1. menu Tools > Language > For Selection > More...; 2. a Character Formatting dialog with Font tab displayed opens; 3. choose German from the Language dropdown list for "Western Text Font", click OK button. ...then it indeed works. I personally feel this is even more convoluted than the process I used in bug 139288 comment 4. Also it doesn't work if the original language of the field is Chinese (which is shown as Multi-language on status bar), but that's the topic for another bug report. 1. Detailed version information: Version: 7.0.4.2 (x64) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded
(In reply to Ming Hua from comment #5) > Also it doesn't work if the original language of the field is Chinese (which > is shown as Multi-language on status bar), but that's the topic for another > bug report. Or maybe not? Maybe it's the matter of having three different sets of languages - "Western"/"CTL"/"Asian", with separate properties holding each ... so maybe setting the language like you/me do only changes one of those, and the field is using the other. I personally sympathize to what Khaled Hosny wrote in bug 104318 comment 23: "On the long run, we should do away with the idea of Western, CTL and CJK font settings and ... have a single font chooser that sets the fonts for all the three to the same font, the idea that there are only three categories of scripts is outdated and absurd anyway". But this is likely offtopic here.
(In reply to Mike Kaganski from comment #6) > (In reply to Ming Hua from comment #5) > > Also it doesn't work if the original language of the field is Chinese (which > > is shown as Multi-language on status bar), but that's the topic for another > > bug report. > > Or maybe not? Maybe it's the matter of having three different sets of > languages - "Western"/"CTL"/"Asian", with separate properties holding each > ... so maybe setting the language like you/me do only changes one of those, > and the field is using the other. Without knowledge about the code, I can't be sure. But I feel it's likely a different issue because I somehow made a document (attachment 168576 [details] in bug 139288) that displays English date in one locale/UI setting and Chinese date in another setting. (I peeked into the underlying XML a little, the field has no language specified, but seems to have a Chinese-specific date format associated with it.) I'll report it separately once I've figured out the details and let you developers decide.
Created attachment 168734 [details] tescase to reprodcue the bug > I will investigate further and report back. It turns out, the file makes the difference. i attached now a file with which LO 7.0.4.2 and LO 7.1 RC1 fails. It seems that the drawing object in which the date field is in, prevents the language from being applied. But even if I select only inside the drawing object, the language is not applied to the date field.
The field in attachment 168734 [details] has a fixed, explicitly defined, language (German). However, this is not apparent if you right-click the field, choose "Edit Fields...", then in the dialog, click on "Additional Formats..." on the bottom of Format list. The list would have "German (Germany)" selected under "Language". If you scroll to the bottom of the list of languages, and select "Automatic", the field will expectedly start following the language of the surrounding text... but if you look again into the language in the dialog, you would see specific language again, not the "Automatic" entry selected. Same specific language selection is shown when you paste fields by default, so user does not see the difference between fields with language set to automatic (= "get language of surrounding text") and with explicit language (= "use this language, no matter what")... This is a regression: worked OK in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 ("Automatic" entry would be pre-selected in number format dialog). Needs bibisection. Additional observation: the list of languages has "Automatic" entry on the bottom, while the top entry is "Africaans (Namibia)" in en-US UI, and that top entry is separated from the rest of the list, while the expected is Automatic on the top and separated - see bug 114694. *Possibly* the regression could have something to do with fix of that bug.
And it does not depend on being under a text box of a shape or a frame; it works the same if in the main text flow.
Created attachment 168737 [details] Two date fields - first Automatic, second explicitly Russian Additional observation: in Version: 6.4.0.3 (x64), fields have Automatic pre-selected when they have no explicit language; but in that version, the bug document from attachment 168734 [details] is imported with Automatic language (which is wrong, because the explicit language is defined in the field's number format - see '<number:date-style style:name="N10121"...>' in styles.xml). Unlike v.7.1, in 6.4 the number format styles were stored in <office:automatic-styles> in content.xml, not in styles.xml. This might complicate bisection, so this new attachment (created in 6.4) could help bisecting without the additional described problem. The first date field is expected to have Automatic pre-selected in number format dialog's Language.
(In reply to Mike Kaganski from comment #11) > Created attachment 168737 [details] > Two date fields - first Automatic, second explicitly Russian > > Additional observation: in Version: 6.4.0.3 (x64), fields have Automatic > pre-selected when they have no explicit language; but in that version, the > bug document from attachment 168734 [details] is imported with Automatic > language (which is wrong, because the explicit language is defined in the > field's number format - see '<number:date-style style:name="N10121"...>' in > styles.xml). Unlike v.7.1, in 6.4 the number format styles were stored in > <office:automatic-styles> in content.xml, not in styles.xml. This might > complicate bisection, so this new attachment (created in 6.4) could help > bisecting without the additional described problem. The first date field is > expected to have Automatic pre-selected in number format dialog's Language. Bibisected with linux-64-7.0 to https://git.libreoffice.org/core/commit/5326d238d7f98b11886eb4be01f19db73f8eda39 tdf#114694: Make default value in language settings the first element Steps were 1. Select first field 2. Right-click - Edit fields 3. Format - Additional formats Good state Automatic, bad state Russian Yusuf doesn't seem active anymore, so not bothering to add him.