Currently there is only one set of default template for Calc/Writer/.... This default template is good for English contents, but for other languages this template may not be appropriate. For example, for Simplified Chinese users, different Headings and Body Text styles (font size, line height, paragraph spacing, paper size etc) should be applied in order to fit the Chinese document convention. For other UI languages, they may require much different default styles. So, we should: 1. Implement different default template per locale, for each LibreOffice component (Calc, Writer, Draw, etc); 2. The template should be put in the "translations" submodule, so that it only takes effect when a certain UI translation is built and installed. 3. When templates for a certain locale does not exist, then it should fallback to the default English template. Thanks!
Sounds good to me. :D
Over to the UX-advise pile...
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
I don't think that we can provide localized templates for various if not all languages. That's the purpose of the extensions site https://extensions.libreoffice.org/templates
(In reply to Heiko Tietze from comment #4) > I don't think that we can provide localized templates for various if not all > languages. That's the purpose of the extensions site > https://extensions.libreoffice.org/templates If the localized teams want to provide localized templates that we can bundle, that is a good thing to have, but we need to ask devs how feasible it is to achieve before shooting it down. We currently have locale specific page sizes, so having locale templates isnt that much of stretch forward.
OpenOffice.org (and AOO) has localized templates as long as I remember. Templates are organized in language-specific folders under share/template. So the question is more, why LibreOffice has not continued that, and whether the reason is still valid.
I would also like to see localized templates in LibO. Most of my customers are not that good in english, so the english templates are not very usefull to them.
Gabor, didn't you implement this request?
(In reply to Heiko Tietze from comment #8) > Gabor, didn't you implement this request? No, that was bug #89676 which turned out to just request localized names and in that sense, a duplicate of bug #114088 which is indeed fixed for 6.0. Localized template content is a completely different beast, I can't tackle it yet. IIRC, Andras once said these were removed because they raised the installer size considerably.
Installer-Size came to my mind short after I posted my report... What about adding the localized templates to the offline-Help-Installer? It would become an "localized content installer" then. That way not all people would benefit from it (because I think most people don't install the offline helpfile) but it wouldn't bloat the installer and it would be better then pointing users to some extension sites... OR Maybe the templates can be put into an extension that is automatically downloaded (user install) with the current GUI-Language from an trusted Libo-Server?
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
(In reply to bugzilla2 from comment #10) As per your size concern, on Linux the "language packs" are distributed in separate rpm/deb packages, and they are normally downloaded from the "Download LibreOffice" website after the main package. I dont't understand why on Windows build all the languages are included in a single MSI installer. Most users will only install one language, so it makes no sense to include all the lang packs. The most approperiate approach, in my opinion, is to include the templates in lang packs, not in help packs. People may never download those help packs because they can view it online anytime they need help. We should push the users to install the default template of their language for better compatibility.
(In reply to Kevin Suo from comment #12) > I dont't understand > why on Windows build all the languages are included in a single MSI > installer. Most users will only install one language, so it makes no sense > to include all the lang packs. On Windows, the MSI installer will automatically select a small set of languages (for western European locale usually the locale language and English (US), I think) for "Typical" installation, and only installs UI and linguistic tools (spellchecking dictionary, thesaurus, etc.) for those languages. No additional downloading of language packs needed. For users with special needs, they can choose "Custom" installation instead of "Typical", and hand-pick whatever language(s) they want. Regardless the installer size concern, I consider this approach better than Linux's "find the exact language packs I need" one.
(In reply to Kevin Suo from comment #12) > The most approperiate approach, in my opinion, is to include the templates > in lang packs, not in help packs. People may never download those help packs > because they can view it online anytime they need help. We should push the > users to install the default template of their language for better > compatibility. As a Windows user, I always perform a custom install on Windows and do the following: 1. I deselect all but "English (United States)" of the 119 'User interface language' list 2. I deselect all but "English" of the 53 'Optional Components' -> 'Dictionary' list 3. I deselct the "Solver for Non-Linear Programming" bundled extension from 'Optional Components' -> 'Extensions' The Microsoft Installer packaging of course remembers this "customization" for upgrades--so it is only with scratch loads that I peform the selections. That said, while I would have no issue with downloading a set of MSI installers (core, langpack, helppack, "bundled" extensions) to perform the installation or an upgrade, it would *greatly* incease the complexity of the build packaging. And it would disrupt unit testing that is performed during build for all but the core build language (en-US of course)--would the localization . It would also greatly affect the QA process where any localization issues would be stuck into configuration "silos". Currently working with TinderBox builds of master, QA have few issues with duplicating Steps to Reproduce for any locale. More modular installer packaging would greatly impede that. The final facet to consider is how installations would be updated. With templates moved to language packs--there would probably need to be both core .MSI packaging and also .MSP packaging. Again the build and packaging infra would need major refactoring (with dillution of QA effort). So, as a counter proposal. Localization of the XML for the document templates (which really are not that large) and any associated localized graphics/media should go into the i18tools. Localize the templates, yes! But leave the monolithic MSI packaging intact for the Windows builds.
First of all, what is specifically suggested here, when talking about "default template"? Is the template from template manager meant, which is named "Default"? Or is any default is meant, which is set to be default by user? Or are the program defaults meant, which are used by default, when user didn't mark any template as default? Offtopic in reply to comment 12: > I dont't understand > why on Windows build all the languages are included in a single MSI > installer. Most users will only install one language, so it makes no sense > to include all the lang packs. It makes perfect sense. Users struggle with modular installers, even on Linux - try to read any support resource like AskLibO, with all those "Something doesn't work" => "oh, component X was missing". I don't even talk about maintenance complexity. See e.g. bug 124992, which suggests to merge help packages in the same way as we currently have single program package.
(In reply to Mike Kaganski from comment #15) > First of all, what is specifically suggested here, when talking about > "default template"? Is the template from template manager meant, which is > named "Default"? Or is any default is meant, which is set to be default by > user? Or are the program defaults meant, which are used by default, when > user didn't mark any template as default? In my opinion, ALL templates that are in the LibO-Installer should be localized. I think the "default" Template is already localized? At least all the Heading-Names aso are in german in my install. But the templates from the quickstarter or Filemenu (File -> New - Template) are NOT localized (exept the name). So when I choose "business letter"-template for example, the whole content is english and not german. That makes the temlate useless for most users that write non-english letters.
As I explained in the initial bug report, what is suggested here is "default template per locale", which means that for instance if I install the Simplified Chinese langpack then there would be a template in the template manager which should be named as sth like "Simplified Chinese - Default", and if the LibreOfgice UI is in this language then when we create a new document this language specific template should be used by default, rather than the English one. This way, the l10n team can design their template for their language (of cause in case a language does not have their own template then it should fallback to the English one. I am not talking about localized templates. "This default template (i.e., the current english one) is good for English contents, but for other languages this template may not be appropriate."
Actually current template is not good for English too. As it sets printer to letter format, while based on locale it should be A4. It takes some research to find what is causing every new document to change printer settings from A4 to letter.
(In reply to Alfonsas Stonis from comment #18) Your situation is different, and is likely a bug (but you need to explain your setup in your bug 145654 - e.g., what templates you are talking about - have you actually made some pre-defined template active, or are you using no template, which is the default; also full info from help->about and detailed OS locale settings): we try to make *default* creation of documents to get locale settings from LO configuration, and we recently started to clean hardcoded info accidentally contained in templates.
The proposal *seems* to have obvious-looking upsides. However, it also bears downsides. So please consider first if those perceived upsides are real, and actually outweigh the problems. Additional load on localization and packaging are the smaller ones. The real problem that I can see would be at user side, and at global community side. The default template, even though not set active by default, is still used quite often; and having it different for different locales would (1) result in users having (more) different behavior of LibreOffice, with steps working for one user in locale A not working for another using locale B; and consequently, (2) the local communities would be further isolated, having their specific workflows, tutorials, etc., instead of having some increasingly solid community including local communities as integral parts. I realize that the same may be said for everything locale-specific, and I don't think this is very special. But the proposal so far have *not* explained a specific problem it tries to resolve; thus far, it *looks* like "let's do this, because we can". So I suggest *first* to present the specific need, where current single default template makes locales less usable than it could be; and then we need to analyze if those problems could be better addressed by some programmatic changes, rather than by introducing localized default templates.
(In reply to Kevin Suo from comment #0) I suggest to specifically expand this: > For example, for Simplified Chinese users, different Headings and Body Text > styles (font size, line height, paragraph spacing, paper size etc) should be > applied in order to fit the Chinese document convention. Which changes specifically are needed? Why can't they be implemented using our existing Western/Asian/CTL approach? What requires those - some national standard? some tradition? Where is that explained? Having those specific bits could help to understand if existing tooling is adequate or not.
(In reply to Mike Kaganski from comment #20) > The proposal *seems* to have obvious-looking upsides. However, it also bears > downsides. So please consider first if those perceived upsides are real, and > actually outweigh the problems. I guess you are a English native speaker? So even if it might be hard to believe, not every person in the world does speak or understand English. In my opinion, there should not even be a doubt, that having localized templates is absolutely necessary. Of course you are right, it would be cool if every person on earth would speak/understand perfectly English, but that ist not going to happen soon. Until then, LibO should make every user feel "home" when working with LibO. And giving Users English templates doesn't make them feel "home". Some of them may not even understand what is written there. And even for persons who do speak perfectly English, its a drawback if the business letter template (for example) is in English and you have to change so much to make it fit your language, that its even faster to start from scratch then use a template. So as said, there should be no doubt, that localized templates are a good thing. BTW: There must exist a possibility for localized templates already, as the Impression-Templates ARE already localized...
(In reply to bugzilla2 from comment #22) > I guess you are a English native speaker? I am Russian living in Moscow. But that is unrelated. > So even if it might be hard to > believe, not every person in the world does speak or understand English. In > my opinion, there should not even be a doubt, that having localized > templates is absolutely necessary. In the following, you didn't describe even one thing, except your false ideas that *current* templates bundled in LibreOffice need to be English. If you tried to read what I wrote in comment 19, you could learn that "we recently started to clean hardcoded info accidentally contained in templates", and could guess that ideally the templates are locale-neutral. Please do not try to attack people based on your totally wrong assumptions (about who your opponent is, as well about how the program works / what can be done without implementing specific proposal presented here). Ant last: I didn't write "this must not be implemented". My request was to *clarify* the request, so that the need be absolutely obvious without any "this can't be bad" vague ideas.
@Mike Kaganski If I gave you the impression, that I was attacking you, I really beg you pardon for that. Attacking anyone was not my intention. I just wanted to add my opinion on that. Because to me it sounded as if you would doubt, that having localized templates is a good idea and we all should live with English instead. So, maybe I just didn't really understand your post. In the end, its just another example of how important localized templates are :D > If you tried to read what I wrote in comment 19, .... I have read that comment too, but I didn't refer to that, because it seems like a printing issue.
(In reply to bugzilla2 from comment #24) > Because to me it sounded as if you would doubt, that > having localized templates is a good idea Yes I would :-) > and we all should live with English instead. And *this* is not what I wrote. I *suspect* (and no, I'm not 100% sure that I'm right) that most, or many even all, of the perceived problems might be solved by *fixing* existing *common* templates, and making sure that existing templates are *not English*, but locale-neutral (which detail I repeat again).
(In reply to Mike Kaganski from comment #25) Let me maybe clarify. As requested in comment 0, and repeated in comment 17, this proposal is specifically about the "Default" template. It is not about general availability of localized templates; it is also not about documents created without any templates. So this specific proposal needs to clarify why some workflow (1) needs the Default template (it isn't properly handled by "use a specialized non-"Default" template, e.g. also bundled, or available as an extension"); (2) requires the template to include locale-specific information; and (3) this all (having those settings in the Default template) can't be implemented by existing mechanisms, such as clearing up the shared common template to eliminate locale information, and making sure that in the absence of that information, it is populated from current defaults derived from user-configured locale. I definitely would like if we can avoid having multiple *Default* templates, if that is possible technically. Note that I do not say that users must "suffer" because of that; I only tell that possibly we may provide the *same* wanted ideal user experience with different technical means - and that's why it's so important to understand specifics what is current problems.
I think a lot of confusion here comes from the fact, that there are two different kinds of templates discussed in this report. With respect to the original reporter, this is about the default "style" template. Right? Wheres I and some others talk about default "document" templates. Not sure what the correct terms for those two different things are though. If I understand Mike right, localized default "document" Templates are already possible? So its "just" a matter for the localization teams providing localized document-templates? So should we split this report into a part for the default STYLES template and one for default-document-templates to not have so many misunderstandings? Or ist it unnecessary because localised default "document"-templates are already possible, which would render any discussion about it useless?
(In reply to Mike Kaganski from comment #26) > So this specific proposal needs to clarify > why some workflow (1) needs the Default template (it isn't properly handled > by "use a specialized non-"Default" template, e.g. also bundled, or > available as an extension"); (2) requires the template to include > locale-specific information; and (3) this all (having those settings in the > Default template) can't be implemented by existing mechanisms, such as > clearing up the shared common template to eliminate locale information, and > making sure that in the absence of that information, it is populated from > current defaults derived from user-configured locale. I am not a heavy Writer user and knows little about Writer templates (or template in general). But since both the reporter Kevin and I are simplified Chinese (zh-CN) users, I think I understand him better than most people on Bugzilla and want to chime in. Technical details aside (when to use the "Default" template, when to not use any template at all; whether it's better to have one default template for all locales, or to have locale-specific ones), I think the issue boils down to that Western text documents and Chinese text documents have fundamental formatting conventions, and therefore users have different expectations. The current situation is that Writer with default configuration, even with zh-CN locale and zh-CN UI, doesn't meet the expectations of Chinese users. The most commonly mentioned example is the formatting of ordinary paragraphs. The formatting convention for Chinese text is "first line indent of two character width, no extra space between paragraphs". I believe traditional Chinese (zh-TW and zh-HK) and Japanese also have similar conventions (though Japan uses one-character indent at the start of paragraph). Now LO provides the special length unit "Character/ch" when CJK is enabled, but AFAIK it's not set to default for indents (and the implementation has room for improvement, but that's another story). So for Chinese Writer users, no matter he/she uses "Default" template or not, the first thing to do is adjusting formatting/style and set them to the Chinese convention. Is template the correct approach to solve this issue? Would resolving this difference achievable with a single "Default" template? If not, is it better to have locale-specific template, or is it better to just add a "Chinese Text" template, and have the zh-CN UI to translate the two "Default" and "Chinese Text" templates to "Western Text" and "Default" in Chinese instead? The aspiring l10n community member probably needs a lot of input from developers here to figure out where to work on next.
(In reply to Ming Hua from comment #28) > [...] that Western text documents and Chinese text documents have fundamental > formatting conventions, and therefore users have different expectations. Sorry for the typo, I meant "have *fundamentally different* formatting conventions" here.
LBP started to clean up the shipped Writer templates for bug 143956.
(In reply to Mike Kaganski from comment #19) > (In reply to Alfonsas Stonis from comment #18) > > Your situation is different, and is likely a bug (but you need to explain > your setup in your bug 145654 - e.g., what templates you are talking about - > have you actually made some pre-defined template active, or are you using no > template, which is the default; also full info from help->about and detailed > OS locale settings): we try to make *default* creation of documents to get > locale settings from LO configuration, and we recently started to clean > hardcoded info accidentally contained in templates. Version: 7.2.2.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: qt5 (cairo+xcb) Locale: en-AU (en_AU.UTF-8); UI: en-US Ubuntu package version: 1:7.2.2-0ubuntu0.21.10.1 Calc: threaded Locale is AU, printer is A4, but Calc has no template at all and all documents are in Letter format.
*** Bug 145654 has been marked as a duplicate of this bug. ***
Kevin Suo committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5da75fcb400579d11430ec3d4c29b4646797fc5c Templates: tdf#86483: Add "Localization" category and add a template for zh_CN It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jun Nogata committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/feeb3a4604daa113894bdaa8c8698e0ded97050c Template: tdf#86483: Add Japanese template to the Localization category It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Laurent, can we resolve this ticket as WFM since you omitted the localized variables from all Impress templates?
(In reply to Heiko Tietze from comment #35) > Laurent, can we resolve this ticket as WFM since you omitted the localized > variables from all Impress templates? I wonder if "FIXED" would be more appropriate as two localized templates were added in l10n [1]. But shall we keep this report open to add new localized templates? [1] https://opengrok.libreoffice.org/xref/core/extras/source/templates/l10n/
(In reply to Laurent Balland from comment #36) > [1] https://opengrok.libreoffice.org/xref/core/extras/source/templates/l10n/ extras/source/templates/l10n/ is under control by the locale community, I wouldn't mess with them :-). => fixed in various tickets by Laurent Balland bug 158205 but 158206 bug 158202 bug 158203 bug 158204 and many more