Now that I think about it, it would be indeed much faster if I add a shortcut on the desktop, rather than searching through the Start menu lmao
If I had it, I’d removed it (and re-saved my templates after that).
Only true for LibreOffice’s own bundled “templates” for use from within file managers. Nothing wrong with that, though.
May or may not be important (and for most, it’s unimportant, until they are very advanced users understanding what they do).
This is not “outright incorrect”. My setup is the same. I customised it so that my new templates go automatically into /home/<user>/Templates/ instead of the hidden ~/.config/…. It works fine.
you mean, it works fine in the specific scenario that that @TheFighter137 has - using it from within a file manager? We are discussing a specific scenario, you know 
Yeah I quite like the Templates folder actually
It helps if one day I have to modify X template (btw thanks for you suggestion on my list style)
I don’t think I am in this context. I feel there is something wrong with @TheFighter137’s procedure. I mean the feature works fine when used correctly (as intended?). So the solution may be a change in @TheFighter137’s routine.
In LO → Templates → right-click → Edit?
Yeah you’re not wrong haha, that’s another way
Although, I wonder which other programs could use the Templates folder
No, the file manager uses the user’s templates directory as intended, and that flow is OK. That directory is designed that way; and (ab)using it for app-internal templates is wrong (done by someone misunderstanding it all).
See also: configuration - XDG user directories - Unix & Linux Stack Exchange
Now that you’re talking about it, I may know why there are two saving locations saved for Templates :
Linux Mint comes with an older version of LO by default, maybe it had the Templates folder as the default directory ; I recently uninstalled this older version and installed the latest one, which may have the more sensible app-only directory
Filed tdf#165860.
Thanks for that
Funny quote: @TheFighter137 was quoting me there, even if this is not shown. So the method is mine.
.
I know the implications, but actually my “method of work” is quite different, so the loss of connection to an originating template doesn’t matter. I only wished to illustrate that the results he got were related to his use of context-menu of a selected .ott-file.
I could recreate your issue under KDE Plasma.
What I understand:
When you right-click in the file browser, a menu pops up offering to create a new document. This menu proposes a list of all files contained in the Templates directory in addition to the default choices (.txt, .html, …). Selecting anyone of these files will copy it to the click location.
The cause of the problem:
The Templates directory is named according to layman signification. This translates into computer terms as an initial contents file. The file is simply renamed without change.
The Create>New File feature is quite basic. It has no idea that some applications make a distinction between a prototype and a production file. LO has “prototypes”. When you open them, they are instantiated and “customised” to yield a real document after some internal preprocessing.
The file browser can’t emulate this preprocessing. This is why you still have an .ott after the copy and not an .odt which is created only after opening the LO template.
How to fix:
@mikekaganski tells me it is wrong to store LO templates into the Templates directory because they rely on a different approach. Though I understand the point, I don’t fully agree with him.
The main point is that LO-templates must be processed before producing a “real” document. This is effectively incompatible with file browser semantics.
However, if your Templates directory contains nothing else, you can go on but activate your templates only from inside LO. If you also need “traditional” initial-contents files, then create a dedicated LO-template directory and designate it in Tools>Options, LO>Paths. Of course, the templates can only be activated from inside LO.
In any case, this implies a change in your procedure.
That’s very well explained
In my specific case, I will simply add a desktop shortcut to Writer