Re: Suggestion: No more language packs for macOS as they are fundamentally broken

On Sat, May 23, 2020 at 9:32 AM Eivind Samseth wrote: > > Here’s the way you can distribute localizations on macOS > 1. Include all localizations in the standard download (used by all Apple > software, MS Office etc.) > 2. Offer precompiled .app bundles in the language of choice (used by Firefox)

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

Am 15.06.20 um 11:33 schrieb Tor Lillqvist: > (Sorry, my fingers slipped somehow and my previous reply had no of my > own text.) > > 4) create a real macOS installer package (native macOS installer > program, not a runnable script like the langauge pack "installer"), > similar to the w

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

(Sorry, my fingers slipped somehow and my previous reply had no of my own text.) 4) create a real macOS installer package (native macOS installer > program, not a runnable script like the langauge pack "installer"), > similar to the windows msi that allows to customize the installation > and pick

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

On Mon, 15 Jun 2020 at 12:08, Christian Lohmaier wrote: > On Sat, May 23, 2020 at 9:32 AM Eivind Samseth wrote: > > > > Here’s the way you can distribute localizations on macOS > > 1. Include all localizations in the standard download (used by all Apple > software, MS Office etc.) > > 2. Offer p

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

> As such 1 or 2 would be the preferred option if we were to design the > system today, agree? > Yes. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

Hello, to take a step back: Here’s the way you can distribute localizations on macOS 1. Include all localizations in the standard download (used by all Apple software, MS Office etc.) 2. Offer precompiled .app bundles in the language of choice (used by Firefox) 3. Offer language packs as a separa

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

> > So when you > install help to another directory, to me it seems like a small step to > also install install the langaugepack files to another directory > outside the app. > It's not *installing* the language pack wherever we want that is the problem. (That is just a modification to one Apple S

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

On Fri, May 22, 2020 at 4:03 PM Tor Lillqvist wrote: >> >> Selecting "good" languages is a minefield, you will surely annoy lots >> of translators/native language speakers. > > And it is better to have it impossible to install language packs? OK. Languagepacks are not impossible to install. open

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

Hello Tor, I supposed you tried hard to fix this and contact every person who may help here. IMHO, it means we don't have the capacity to provide a localized version of LO for MacOs correctly. Doing an English version + all languages versions or doing 95% languages version, etc. is just a poor ban

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

On Fri, 22 May 2020 at 21:05, Christian Lohmaier wrote: > Probably too terse. I meant solving the help issue → installing the > help into a different directory and dealing with what you would have > to deal with languagepacks, meaning handling the different versions of > main LO, providing some u

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

Hi *, On Thu, May 21, 2020 at 12:36 PM Tor Lillqvist wrote: > > A much easier solution would be for TDF to simply stop building and > distributing language packs for macOS. > > Instead, my suggestion is that what should be distributed is: > > A build with a multitude of UI languages. Not all, bu

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

> > > > Selecting "good" languages is a minefield, you will surely annoy lots > of translators/native language speakers. > And it is better to have it impossible to install language packs? OK. > Both complains of "why do I have to download language xy that I never > use/never heard of" and "why

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

On Thu, May 21, 2020 at 12:48 PM Eivind Samseth wrote: > > Sounds like a good solution, as the current method is fundamentally broken > wrt code-signing, Please keep problems separate. Gatekeeper validation happens way before anything is dumped into the .app directory that can invalidate the sig

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

> > > Cool, so if we apply file system compression to the .app bundle it will > likely be around 1 GB on disk, But how to do that? There is nothing in the LibreOffice Vanilla build configuration etc that would say "enable file system compression". Maybe it is a side-effect of it being distributed

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

> On 22 May 2020, at 11:45, Christian Lohmaier wrote: > >> So LO would still beat the 5.3 GB in total for the competition :) > > Yes, LO would be around 3GB... Cool, so if we apply file system compression to the .app bundle it will likely be around 1 GB on disk, which is only 200-300 MB more

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

On 22.05.2020 12:41, Adolfo Jayme Barrientos wrote: > On 21/05/2020 12:35, Tor Lillqvist wrote: >> * A build with a multitude of UI languages. Not all, but those with >> "good enough" coverage. This build would also contain all >> dictionaries (even for languages for which the UI is not i

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

On 21/05/2020 12:35, Tor Lillqvist wrote: > * A build with a multitude of UI languages. Not all, but those with > "good enough" coverage. This build would also contain all > dictionaries (even for languages for which the UI is not included) Let's draw that arbitrary line of coverage at..

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

On 22.05.20 00:32, Thorsten Behrens wrote: > ...download extra languages dynamically, > and then hold it - per user - in the configuration subdirectory? This "extensions way" would be my preferred choice too. Besides the hurdles Tor mentioned, another problem is the requirement from l10n to have

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

Technically, I wonder though - in case the all-in-one build would be > deemed too bulky, couldn't we download extra languages dynamically, > and then hold it - per user - in the configuration subdirectory? > > But that is essentially the first approach I tried, where a language pack would be instal

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

> > > The rationale for always including all dictionaries being that they are > small enough so that it doesn't hurt? > > The rationale is that what dictionaries needed by a user needs is independent of to user interface languages used. I, for instance, would really not want to use LibreOffice in a

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

On 21/05/2020 12:35, Tor Lillqvist wrote: * A build with a multitude of UI languages. Not all, but those with "good enough" coverage. This build would also contain all dictionaries (even for languages for which the UI is not included) * A number of other builds each with some geograph

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

Mike Kaganski wrote: > I suggest not to do "geographic subset" builds. One build with > everything included would be the best option - e.g., maintenance-wise > (one single binary; no problem allowing parallel installations for the > last remark; etc.); and also UX-wise (the additional options add >

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

> > > I see the LO Vanilla build is 2.2 GB vs 0.8 GB for a single language build > One needs to also take into consideration that current macOS has a file-level transparent compression in the file system. On my machine, LibreOffice Vanilla.app is (as you say) 2.2 GB nominally, but (at the moment)

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

Just to correct myself LO Vanilla uses file compression so the size on disk is only 0.7 GB! I don’t think the current TDF builds do that? Would alleviate completely any concerns about disk space usage FYI: Word etc. do not use compression on their .app bundle (base) EivindsMBP2015:Applications

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

On 21.05.2020 13:35, Tor Lillqvist wrote: > * A build with a multitude of UI languages. Not all, but those with > "good enough" coverage. This build would also contain all > dictionaries (even for languages for which the UI is not included) > * A number of other builds each with some ge

Re: Suggestion: No more language packs for macOS as they are fundamentally broken

Sounds like a good solution, as the current method is fundamentally broken wrt code-signing, and is an extra step for users How big would the .app bundle be? That would be the only drawback I see the LO Vanilla build is 2.2 GB vs 0.8 GB for a single language build This is still less than MS Off

Re: Suggestion

We handle issues and requests in our bugtracker [1]. The particular question has been asked for in https://bugs.documentfoundation.org/show_bug.cgi?id=37134. If you want to learn more about the background search the web for SDI vs. MDI (single/multi document interface). [1] https://wiki.docum

Re: Suggestion: Finding missing words in dictionaries via web scraping and natural language processing

On 08/17/2017 11:20 AM, Michael Stahl wrote: > by "missing words in dictionaries", do you mean that if "teh" was used > as an archaic spelling of "tea" in a work of Shakespeare (completely In Pinyin, the transliteration is "de". In Wade-Giles, the transliteration is "teh". For people who quote D

Re: Suggestion: Finding missing words in dictionaries via web scraping and natural language processing

On 08/17/2017 10:08 AM, Andrej Warkentin wrote: > So I thought this could be used to find (or at least help finding) most > missing words in dictionaries for all languages. Back when the OOo dictionary for Afrikaans was created, a program was run through the dictionary corpus, excluding words th

Re: Re: Suggestion: Finding missing words in dictionaries via web scraping and nlp

by "missing words in dictionaries", do you mean that if "teh" was used as an archaic spelling of "tea" in a work of Shakespeare (completely made up and hypothetical example), that we should add "teh" to the dictionary and no longer flag it as a wrongly spelled word? Of course not. The result o

Re: Suggestion: Finding missing words in dictionaries via web scraping and natural language processing

On 17.08.2017 12:08, Andrej Warkentin wrote: > Hello, > > in a talk at the PyData Berlin meetup I saw this project: > https://github.com/lusy/hora-de-decir-bye-bye , where spanish articles > are scraped and searched for english words. In order to identify english > words she used the dictionari

Re: Suggestion

Markus, I had asked for alternate syntax suggestions on what formatting codes should be used and received silence. I have no real desire to create an entire unit feature branch for this feature, but only to make this one change. I am content to write the changes as I have outlined them, and then

Re: Suggestion

Hey Rick, On Thu, Jan 28, 2016 at 7:28 PM, Rick C. Hodgin wrote: > Since I haven't heard back, I'll go ahead and develop this using the > syntax I propose. It's easily changed later. > > Also two more additions: > (1) Adding a separator symbol for decimals, as in 1234.4321 being > "1,234.432,1

Re: Suggestion

Since I haven't heard back, I'll go ahead and develop this using the syntax I propose. It's easily changed later. Also two more additions: (1) Adding a separator symbol for decimals, as in 1234.4321 being "1,234.432,1" (2) Adding a feature to Writer which allows an export of every word using a

Re: Suggestion

On Tue, Jan 26, 2016 at 5:50 AM, Eike Rathke wrote: > Hi Rick, > > On Monday, 2016-01-25 16:26:53 -0500, Rick C. Hodgin wrote: > > > On Mon, Jan 25, 2016 at 3:21 PM, Rick C. Hodgin > > > > On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke wrote: > > >> On Friday, 2016-01-08 19:52:49 -0500, Rick C. H

Re: Suggestion

Hi Rick, On Monday, 2016-01-25 16:26:53 -0500, Rick C. Hodgin wrote: > On Mon, Jan 25, 2016 at 3:21 PM, Rick C. Hodgin > > On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke wrote: > >> On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote: > >> > >> > The category is called *"Metric."* > >> > >

Re: Suggestion

On Mon, Jan 25, 2016 at 3:21 PM, Rick C. Hodgin wrote: > > > On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke wrote: > >> Hi Rick, >> >> On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote: >> >> > The category is called *"Metric."* >> > >> > When conveying fractional values, such that 1.2345

Re: Suggestion

On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke wrote: > Hi Rick, > > On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote: > > > The category is called *"Metric."* > > > > When conveying fractional values, such that 1.2345E-08 (which is > > 0.000,000,012,345), it would do so in a metric-relat

Re: Suggestion

On Wed, Jan 13, 2016 at 1:47 PM, Wols Lists wrote: > On 13/01/16 18:33, Rick C. Hodgin wrote: > > > > > > On Wed, Jan 13, 2016 at 1:24 PM, Wols Lists > > wrote: > > > > On 13/01/16 17:37, Rick C. Hodgin wrote: > > > Wol, I don't understand your objection.

Re: Suggestion

On 13/01/16 18:33, Rick C. Hodgin wrote: > > > On Wed, Jan 13, 2016 at 1:24 PM, Wols Lists > wrote: > > On 13/01/16 17:37, Rick C. Hodgin wrote: > > Wol, I don't understand your objection. You have seen the spreadsheet I > > created which demonstrat

Re: Suggestion

On Wed, Jan 13, 2016 at 1:24 PM, Wols Lists wrote: > On 13/01/16 17:37, Rick C. Hodgin wrote: > > Wol, I don't understand your objection. You have seen the spreadsheet I > > created which demonstrates the various behaviors. Which one of them is > > incorrect? > > Sorry, I haven't seen the sprea

Re: Suggestion

On 13/01/16 17:37, Rick C. Hodgin wrote: > Wol, I don't understand your objection. You have seen the spreadsheet I > created which demonstrates the various behaviors. Which one of them is > incorrect? Sorry, I haven't seen the spreadsheet ... > > The whole purpose of the Metric add-on is to aut

Re: Suggestion

On 12/01/16 21:11, Rick C. Hodgin wrote: > The values won't round. You misunderstand me. They shouldn't round. And based on what the user has selected, they > will display to the nearest power of 3 (10^(k*3)), or in an explicit > form. The default option will be to auto-range the values into th

Re: Suggestion

I don't know what in my message headers causes filters on this list to divert my posts to moderated status but here goes another one. Hi Rick, As I stated in another post to this list yesterday, I am a LO user. FWIW, I think of this idea as "human readable" formatting rather than as "metric" f

Re: Suggestion

The values won't round. And based on what the user has selected, they will display to the nearest power of 3 (10^(k*3)), or in an explicit form. The default option will be to auto-range the values into their metric named range. Here are some examples: http://www.libsf.org/misc/libreoffice_metric

Re: Suggestion

On 12/01/2016 13:22, Rick C. Hodgin wrote: The important part of the Metric feature is that it always wraps the value to the nearest power of 3, and shows values in those powers. 0.1234 would be shown as 123.4 milliunits, or 1,234 microunits, for example (however the user has set it up), and n

Re: Suggestion

> The important part of the Metric feature is that it always wraps the value to the > nearest power of 3, and shows values in those powers. 0.1234 would be shown > as 123.4 milliunits, or 1,234 microunits, Correction: should be 123,400 microunits. Best regards, Rick C. Hodgin __

Re: Suggestion

On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke wrote: > Hi Rick, > > On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote: > > > The category is called *"Metric."* > > > > When conveying fractional values, such that 1.2345E-08 (which is > > 0.000,000,012,345), it would do so in a metric-relat

Re: Suggestion

Hi Chris, On Tuesday, 2016-01-12 12:28:16 +1100, Chris Sherlock wrote: > > All in all this sounds a bit like the idea behind the unit verification > > that has been planned and partly been implemented in a feature branch. It > > might be a good idea to have a look at that before implementing it

Re: Suggestion

Hi Rick, On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote: > The category is called *"Metric."* > > When conveying fractional values, such that 1.2345E-08 (which is > 0.000,000,012,345), it would do so in a metric-relative way using the > standard milli (10^-3), micro (10^-6), nano (10

Re: Suggestion

> On 12 Jan 2016, at 4:00 AM, Markus Mohrhard > wrote: > > Hey Rick, > > [snip] > > All in all this sounds a bit like the idea behind the unit verification that > has been planned and partly been implemented in a feature branch. It might be > a good idea to have a look at that before implem

Re: Suggestion

On Sun, Jan 10, 2016 at 01:37:17PM -0500, Rick C. Hodgin wrote: > I've been able to setup a Linux Mint 17.1 install with build-prep, git > clone libreoffice, compile it (whew!), run it from the command line, make > the kdevelop projects, load module_sc into kdevelop, (...) I don't > know if there'

Re: Suggestion

Hey Rick, On Sat, Jan 9, 2016 at 1:52 AM, Rick C. Hodgin wrote: > I am a developer and would be willing to make these changes for the > project, but I've never worked on the LibreOffice code base and would need > some help getting started with the correct source files. > > - > I had an idea

Re: Suggestion

Thank you, Julien! Thank you, Chris! I've been able to setup a Linux Mint 17.1 install with build-prep, git clone libreoffice, compile it (whew!), run it from the command line, make the kdevelop projects, load module_sc into kdevelop, and I've located the NumberFormatPropertyPanel.* files in modu

Re: Suggestion

Hi Rick, IMO, the *very* first step any new developer needs to undertake is to get the LO codebase from git, compile it and then make sure it runs. This might sound facetious to a newcomer, but actually it’s not. That is normally the first stumbling block for any new starter (it was for me) an

Re: Suggestion

Welcome Rick! Here's the start page for those who want to contribute on dev part: https://wiki.documentfoundation.org/Development Julien -- View this message in context: http://nabble.documentfoundation.org/Suggestion-tp4171215p4171224.html Sent from the Dev mailing list archive at Nabble.com

Re: Suggestion for the use of pre-written responses

jphilipz wrote > .. > So i'd like to propose the creation a wiki page of pre-written responses > that we can all use. I have created the wiki page at < > https://wiki.documentfoundation.org/QA/BugTriage/Pre-Written_Responses > > and will be adding entries to it, though i have very little knowledge

Re: Suggestion for Calc

Hi, Test schrieb: Hi everyone, I hope I’m on the right place to write my suggestion / feature request. No, it is the wrong place. This list would be suitable, if you are going to implement the feature yourself and need some code pointers. For discussion whether the feature is useful and to

Re: suggestion for adding sdk/lib to pluginapp.bin or libuno_sal.so symlink in ure/lib

On 05/23/2014 08:59 AM, Richard PALO wrote: @@ -73,7 +65,7 @@ $(eval $(call gb_Executable_use_external )) # the orignal dmakefile said: don't ask, it's ugly -ifeq ($(OS),SOLARIS) +ifeq ($(OS),XSOLARIS) $(eval $(call gb_Executable_set_ldflags,pluginapp.bin,\ -z nodefs \ )) BTW, for the

Re: suggestion for adding sdk/lib to pluginapp.bin or libuno_sal.so symlink in ure/lib

Le 21/05/14 10:56, Stephan Bergmann a écrit : On 05/21/2014 07:13 AM, Richard PALO wrote: S=/var/tmp/pkgsrc/misc/libreoffice4/work/libreoffice-4.2.4.2 && I=$S/instdir && W=$S/workdir && g++-Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -L$I/ure/lib -L$I/program -z nodefs $W/Cx

Re: suggestion for adding sdk/lib to pluginapp.bin or libuno_sal.so symlink in ure/lib

On 05/21/2014 07:13 AM, Richard PALO wrote: S=/var/tmp/pkgsrc/misc/libreoffice4/work/libreoffice-4.2.4.2 && I=$S/instdir && W=$S/workdir && g++-Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -L$I/ure/lib -L$I/program -z nodefs $W/CxxObject/extensions/source/plugin/unx/npwrap.o $

Re: suggestion for feature to improve document quality

> building lists of every word in the > document would need implementing differently if it was to scale to large > documents. Or to languages more complex than English in their word structure. Like languages that use inflections (for gender, number, function, tense and whatnot). Basically, to be u

Re: suggestion for feature to improve document quality

Hi, Johan Henriksson wrote > * First, the word count should be supplemented with a more elaborate > dialog > that counts the occurrence each word, and shows them sorted by count. This > helps finding the most annoying words and systematically eliminating them. There is an extension for this. htt

Re: suggestion for feature to improve document quality

Hi Johan, On Tue, 2012-10-23 at 13:17 +0200, Johan Henriksson wrote: > I want to propose a new feature to OO. So - this is the developers' list for discussing patches, code pointers, reviewing changes, and discussing technical issues - it is not a place for people to post their wish-lists

Re: suggestion for feature to improve document quality

Hi Johan, Johan Henriksson píše v Út 23. 10. 2012 v 13:17 +0200: > I want to propose a new feature to OO. One of the final tasks when > writing, for example, grant applications, is polishing the language. > OO currently has a thesaurus feature which is very useful for killing > off repetitions, b