though the literal date is given a capital first letter for months and days in english, The possibility to have uncapitalised words should not be forbidden. So at least for the date field for example in the header or footer there should be the option to turn off the auto capitalisation disregarding what locale was set. As a general rule for anything that is automatic there should an easy way for users to turn it off.
I also couldn't correct it manually. cc: Design Team for further input
Can you make a working example please. When I type "Blood monday" or "It's october" the two dates are kept lowercase (tools > options > language > locale set to EN_US and applied to the document).
(In reply to Heiko Tietze from comment #2) > Can you make a working example please. When I type "Blood monday" or "It's > october" the two dates are kept lowercase (tools > options > language > > locale set to EN_US and applied to the document). Heiko, the request is about fields => back to UNCONFIRMED
Guess this field content is not autocorrected but inserted according system locale whatever. Eike, what do you think?
Formatted date fields' day and month names are taken from locale data as is, there is no auto-capitalization.
(In reply to Eike Rathke from comment #5) > Formatted date fields' day and month names are taken from locale data as is, > there is no auto-capitalization. So I suggest to resolve as NAB.
(In reply to Heiko Tietze from comment #6) > So I suggest to resolve as NAB. But could at least be an enhancement. I think it should be possible to add date fields with lowercase. I couldn't find a way to do this.
You could insert a spreadsheet cell per OLE with =LOWER(TEXT(MONTH(NOW()),"mmmm"))
(In reply to Heiko Tietze from comment #8) > You could insert a spreadsheet cell per OLE with > =LOWER(TEXT(MONTH(NOW()),"mmmm")) itt788, does this solve your problem?
EN_US and EN_UK will have first letter in uppercase but this can be changed. I know its a workaround but still. steps to do file => properties => custom properties => add property give some name => text = text => value enter the date close with ok then in footer or header insert => field => more fields => tab DocInformation => select custom click given name and insert close And yes its a bit off work but it can be done.
(In reply to Xavier Van Wijmeersch from comment #10) > text => value enter the date You can also set a variable in the fields dialog. However, this fix value will not change when time passes by.
it seems i have not explicitly precised that i was talking of the "date" field that LO will replace with "today's" or another date if set by the user with the option to set the style (DD/MM/YYYY or DD/MM/YY ... or literal date). I think the "date" field in a spreadsheet cell is technically different. In my case it's for the one that is available in the fields list for the footer or header for example. I tried the suggested solution "file => properties => custom properties => add a property ..." This is not a solution. My request is just about removing the forced capitalisation in the "date" field when set to be displayed with a "literal" style. There is no place where people should be forced to use capital letters. This kind of things should not exist in text processing software or office tools. Therefore i personally consider it as a bug.
itt 788, yes I understand your request. Perhaps "autocapitalisation" leeds to a wrong direction. I changed bug title and I think it's an enhancement request. Steps to reproduce: 1. Open a document 2. Open fields dialog (strg+2) 3. Document => date: You can't choose a date with lower case letters 4. Additional formats: You can't choose a date with lower case letters Suggestion: Add an option to Format Number dialog.
(In reply to Dieter Praas from comment #13) > Suggestion: Add an option to Format Number dialog. (In reply to Eike Rathke from comment #5) > Formatted date fields' day and month names are taken from locale data as is, > there is no auto-capitalization. The request is to introduce some kind of auto_un_capitalization. In particular with fields I doubt it's possible cross-plattform and -application. => WF
(In reply to Heiko Tietze from comment #14) > The request is to introduce some kind of auto_un_capitalization. In > particular with fields I doubt it's possible cross-plattform Aren't "LOWER" function in Calc and Format->Text->Lowercase in Writer cross-platform? > and -application. Do you actively limit LibreOffice to only be a common subset of other office suites? How about limiting ourselves to what notepad offers? > => WF Disagree.
(In reply to Mike Kaganski from comment #15) > Aren't "LOWER" function in Calc and Format->Text->Lowercase in Writer > cross-platform? To my knowledge there is no lower() (or any similar) function in Writer - except using a macro. > > => WF > > Disagree. That's why I added you to CC :-)
(In reply to Heiko Tietze from comment #16) > (In reply to Mike Kaganski from comment #15) > > Aren't "LOWER" function in Calc and Format->Text->Lowercase in Writer > > cross-platform? > > To my knowledge there is no lower() (or any similar) function in Writer - > except using a macro. As Mike said, it's Format -> Text -> lowercase (which actually does not format but convert the text). CharClass::lowercase() is cross-platform (and locale dependent).
How about a solution per macro? Option VBASupport 1 Sub Main Dim oDoc As Object Dim oText As Object oDoc = ThisComponent oText = oDoc.Text oVCurs = oDoc.CurrentController.getViewCursor() oTCurs = oText.createTextCursorByRange(oVCurs.getStart()) sToday = LCase( WeekdayName( WeekDay( Now() ))) oText.insertString( oTCurs, sToday, FALSE ) End Sub
As I understand the request, it's about some control in (different?) fields editor that controls its casing (e.g., "No case change"/"Lowercase"/"Uppercase"/"Sentence case"), which would apply the chosen operation (analogous to what we have in Format->Text) to the result of the field evaluation, *dynamically*. No macro solution could handle e.g. requirements to templates, or to fields displaying print time.
And I don't see a solution that automatically modifies inserted fields. But I'll rest my case and once developer come up with an idea I'm happy to support with a UI solution.
Perhaps the easiest way would be to offer some formats with lower case letters in the format-list
whether date fields must be capitalised or not is a question of grammar and region. Auto-capitalisation must be removed from the code making the date field. Spell checker with its grammar and language options should take care of capitalisation for the whole document on the basis of user settings.
(In reply to itt788 from comment #22) > Auto-capitalisation must be removed from the code making the date > field. Spell checker with its grammar and language options should take care > of capitalisation for the whole document on the basis of user settings. This has no sense. Fields value is not subject to grammar checker (and must not be.)
(In reply to Mike Kaganski from comment #23) > (In reply to itt788 from comment #22) > > Auto-capitalisation must be removed from the code making the date > > field. Spell checker with its grammar and language options should take care > > of capitalisation for the whole document on the basis of user settings. > > This has no sense. Fields value is not subject to grammar checker (and must > not be.) I hope having not been misunderstood. In my previous comment i meant that in whatever language capitalisation is a matter of grammar. Thus the date field should never force either capitalisation or non-capitalisation unless the user wishes so, in which case he must turn on spell-checker with grammar option. Even though in English day names must be capitalised, not everyone like to do so. Libreoffice should allow users to turn off auto-capitalisation for the date field, or whatever other field with similar concern.
(In reply to itt788 from comment #24) > (In reply to Mike Kaganski from comment #23) > > (In reply to itt788 from comment #22) > > > Auto-capitalisation must be removed from the code making the date > > > field. Spell checker with its grammar and language options should take care > > > of capitalisation for the whole document on the basis of user settings. > > > > This has no sense. Fields value is not subject to grammar checker (and must > > not be.) > > I hope having not been misunderstood. > > In my previous comment i meant that in whatever language capitalisation is a > matter of grammar. Thus the date field should never force either > capitalisation or non-capitalisation unless the user wishes so, in which > case he must turn on spell-checker with grammar option. Here it the thing I objected to. The phrase "the date field should never force either capitalisation or non-capitalisation unless the user wishes so, in which case he must turn on spell-checker with grammar option" implies that the spell-checker would somehow suggest and/or change capitalization of the date field text. But *that* will not happen, because field data is not spell-checked in any way. From spell checked point of view, a field is some kind of external object, like image. Its content is not something that user types freely, and is calculated automatically from some source data. Thus an expectation that spell checker would do something instead of the field itself is wrong. Thus some method of capitalization *must* be embedded into the field, or else user will have no way to control that (just the same way as it it now, only the opposite direction: when one wants capitalization, that would be impossible).
(In reply to Mike Kaganski from comment #25) [ ... ] From spell checked point of view, a field is some > kind of external object, like image. Its content is not something that user > types freely, and is calculated automatically from some source data. Thus an > expectation that spell checker would do something instead of the field > itself is wrong. you're pointing a purely technical point, and this is not how it should be. In French for example, day and month names follow the same rule as common names, i.e. capitalisation is only done if they occur as first word in a sentence. So if autocapitalisation were user settable for date fields and ON, then capitalisation will happen even in the middle of a sentence if that's where the date field is. That forces users to check manually each date entry in their document. For a text processor that claims to check grammar, that should be called a bug. [ ... ] > Thus some method of capitalization *must* be embedded into > the field, or else user will have no way to control that (just the same way > as it it now, only the opposite direction: when one wants capitalization, > that would be impossible). There seems to be such a long way to go. LO is a fork from a project that was first released in 1985!
(In reply to itt788 from comment #26) > (In reply to Mike Kaganski from comment #25) > > [ ... ] > From spell checked point of view, a field is some > > kind of external object, like image. Its content is not something that user > > types freely, and is calculated automatically from some source data. Thus an > > expectation that spell checker would do something instead of the field > > itself is wrong. > > you're pointing a purely technical point, and this is not how it should be. Absolutely not. You miss the point entirely. Field is, by its nature, not a random text. Its text is *meant* to be *generated by program* following the field's rules from some data (e.g., a number representing a date). There's no concept of "field data modified by user". Hence there's no "field text + spell check edits". This is *how it should be*: any changes of the field content may only be applied by modifying the field properties, not editing text from outside. Which means that field properties must provide user a means to define wanted capitalization, not some "spell check" or any outside tool.
(In reply to Mike Kaganski from comment #27) > Field is, [ ... ] > not a random text. This is such a harsh statement you do as response to my comment! If i hurt anyone here, be sure this is not intentional. Fields are used where the information users want in their document can be calculated by the computer. That is things like page numbers, arithmetic operations, dates... In my understanding Fields consist in two layers, first, the "code", to make the computer understanding what we want. Second, the way is is represented as per user's wish. Currently for the second layer font and font size are done by the same code as for the rest of the text. Users can select a piece of text and apply his format disregarding the presence or not of a field. If the user wants Liberation Serif any field with alphanumeric characters will follow. That being said i still don't see why auto-capitalisation by an external code cannot be implemented. The first layer is left untouched anyway. MSword capitalises whatever word, field or not, as necessary with Shift+F3. And mind the fact that for a language like french currently the current implementation of date fields can be seen as broken or unsuitable.
(In reply to itt788 from comment #28) > (In reply to Mike Kaganski from comment #27) > > Field is, > [ ... ] > > not a random text. > This is such a harsh statement you do as response to my comment! If i hurt > anyone here, be sure this is not intentional. No, you haven't hurt anyone; and it looks like my use of word "random" might be wrong/harsh, which is not intentional. What *I* tried to express was, that unlike usual text that user types and edits at their will, being in full control of any character of it (which I expressed as "random", but maybe the word is improper; I'm not a native English speaker, sorry), field's text is controlled by the field algorithm. > Fields are used where the information users want in their document can be > calculated by the computer. That is things like page numbers, arithmetic > operations, dates... Exactly. > In my understanding Fields consist in two layers, first, the "code", to make > the computer understanding what we want. Second, the way is is represented > as per user's wish. No. There is no "two layers" here, only one layer of "apply some algorithm to some input data to create some sequence of characters". Field *usually* (except for very special fields like ToC) does *not* care about representation of the characters, it just inserts these characters into the character stream rendered by its "owner", which is some text run. Representation of characters (font, its effects, spacing, etc.) is performed on a layer unrelated to the field; but note that the characters themselves are *never altered* on those outer layers. By the way, the characters of other "random" (sorry for the word) text are *also* not modified by those "representation" layers - which only apply formatting. The process of *modification* (say, replacing one character "a" with another "A") is not part of representation, anyway. In normal text, it's performed when user types something, or otherwise edits (e.g., using automatic edit tools like spell checking); in that process, user *modifies text*, not modifies representation. And again: *field's* sequence of characters is *calculated, not typed*, hence you may not edit it. That said, we have *some* fields that allow free editing of their calculated content: namely, ToC. You may unprotect the field, and type/delete/replace things there at will. But to make that possible, the field must be "calculated once": what I mean is Writer does not re-calculate the field on every change of the document, but calculates it *only* on first insert, and then on explicit commands to update it. Even save-and-reload does not cause its re-calculation; that's why you may have totally out-of-sync ToC in your document, if you forget to refresh it manually. In this case, when Writer keeps the cached text of the field which will not be modified until the next explicit command, it's reasonable to allow user to change that cache at will ... and user should realize that any manual changes there will of course be lost when the field is updated. But for *any* auto-updated field, that does not make sense. Every change in a document, like typing a character somewhere, may trigger automatic refresh of the field text, which would ruin any manual changes to the cached text. That is *wanted* and *expected*, *correct* behavior; it would be *wrong* and a *bug* for a page number field, or a cross-reference field, or any of the multitude of other fields, to not change in those cases. Even for a "fixed date" field, which you may think as "calculated once", it's not so: it's calculated from a fixed date, but variable current locale of the enclosing text - thus when you change the language of the outer text, it will automatically re-calculate its string. So it's also auto-calculated data, and should not allow free-form modification of its cached string. How Word does it is a different thing. The two suites are built around very different concepts; and it's not necessary that a workflow in one of them translates directly to the same workflow in the other. It's done where applicable, but not universally. Also please don't repeat the "for French, it's broken" (which I don't deny) as proof of "the solution that *I* suggest is the only suitable". Yes, the problem needs improving, but that doesn't mean that it only has *that* solution.
(In reply to Mike Kaganski from comment #29) > (In reply to itt788 from comment #28) [ ... ] > No. There is no "two layers" [ ... ] it's quite stunning that a rule that is part of a language that is centuries old, known worldwide, 5th most spoken is not respected by a word processor that is more than 10 years and a fork of a project nearly 30 years old. On top of that, such a debate taking place and when reading you it's clear that it's not going to be solved soon, and absolutely your suggestion is not a solution for the case of french. Should actually french language rules change for libreoffice? Do you realise the problem??? Are you human should i ask?
Note that [NatNum12 MMMM=lower]MMMM (lower/upper/title/capitalize, see [1]) can provide the wanted functionality. [1] https://help.libreoffice.org/latest/en-US/text/shared/01/05020301.html?&DbPAR=CALC#NatNum12
(In reply to Mike Kaganski from comment #31) > Note that [NatNum12 MMMM=lower]MMMM (lower/upper/title/capitalize, see [1]) > can provide the wanted functionality. > > [1] > https://help.libreoffice.org/latest/en-US/text/shared/01/05020301. > html?&DbPAR=CALC#NatNum12 i have tested in version 7.5, by default in french date is in lower case. I don't know when they solved it but either a report was done before this one, in which case it should be mentioned at duplicate. Or the fix should have been mentioned here. I tested the NatNum12 option, it's good. Now in any language the date fields can be set as lower case.