"German comments removal" sounds like a lot of work. It is always very annoying when programmers comment (or even name their variables/functions/whatever) using another language than English.
Most APIs are based on English so this makes a very messy combination. And yet people do it often, hindering the possibility of foreigners to contribute.
A recent example I've run into is the WYSIWYG editing extension for ShareJS, with all comments in Russian. I'd love to reuse it, but this just keeps me away:
Absolutely. Given how much cruft we'd all heard was in there, it really is amazing how they've cleaned it up. Too bad there are two competing projects, but really LO looks like the winner so far.
As someone who's been using LibreOffice regularly since it was made the default office suite in Ubuntu, I can attest personally to its ongoing improvement in usability, performance, and looks. As of today, LibreOffice feels smoother, faster, and prettier to me than OpenOffice ever did.
I can't wait to see what the talented LibreOffice developers decide to do once they have finished cleaning up legacy code and can focus almost exclusively on those things that impact user experience the most.
LibreOffice's usability, performance, and looks are likely to improve dramatically over the next couple of years.
For me, LibreOffice has trumped NeoOffice on the Mac. I just have no reason to support that project. Does anyone know if the NeOffice guys return code back to the LibreOffice master? If so, I could see that as a reason to continue supporting them.
Will pay a lot of money for a Linux-compatible Excel feature-parity version of a spreadsheet.
In fact, most spreadsheets today are created using OOXML, so it might be easier (notionally speaking) than the binary XLS format.
I daresay, there is a very, very large market for this - especially in Asia. I dont need the same for Word or Powerpoint - PDFs work fine in an emergency. For spreadsheets, I dont have an alternative.
It's a tough thing to do -- particularly with Excel -- many spreadsheets include VBA code and other stuff that has dependencies on other parts of the Microsoft stack.
OOXML is a beastly specification, because it's not just a description of how to create a document or spreadsheet -- it includes artifacts to maintain compatibility with MS Office software from the early 90's.
VBA is the big beast - but here is a question from me. What will it take to implement VBA on top of Lua (or any other lightweight,embedded runtimes/VM). Hell, what will it take to implement VBA on top of the V8 engine [1] ? If one can achieve that, then you can pretty much build a spreadsheet as a browser plugin for 80% of the cases. For the rest 20% pathological cases - fine, reboot to windows.
Now, thats's an idea for a Kickstarter. This is the kind of thing that goes on to transform businesses in third world countries - Excel is what prevents the move to Linux more than ANYTHING else.
"According to Microsoft, Excel 2011 for Mac features a full port of the Windows Office VBA environment; in most cases, the OS X and Windows versions of VBA now mirror each other."
Not to mention the various versions of it (e.g ECMA vs ISO, and their revisions) which led to differing and incompatible implementations, numerous areas where things are ambiguous or undefined, and things that are defined by referencing the undisclosed DOC/XLS spec.
Spreadsheets cant work with XLSX - especially things like pivot tables, etc. In fact if you google around, you will see people having serious problems opening a fairly small (in business terms) XLSX in OO/Libre, which opens in a second in Excel.
I'm completely confused by the second sentence here:
"Unfortunately, for one reason and another, despite a delay for a fourth release candidate, there are still some circumstances where an upgrade will not re-register some built-in extensions, and silently exit on first launch (just re-run it). On the down-side that can affect spell-checking dictionaries, and (for some) on the up-side disables Auto-COrrection too."
I'm wondering if it is significant that the second letter in "COrrection" is capitalized? Like, the feature that automatically corrects TWo INitial CAps will be disabled? But some people find that auto-correction annoying and will consider it an "up-side" that it's disabled? Doesn't really make sense to me, but it's all I can think of here.
Most APIs are based on English so this makes a very messy combination. And yet people do it often, hindering the possibility of foreigners to contribute.
A recent example I've run into is the WYSIWYG editing extension for ShareJS, with all comments in Russian. I'd love to reuse it, but this just keeps me away:
https://github.com/rizzoma/ShareJS/blob/master/src/client/ri...
(note: I can read Cyrillic characters and do understand some Russian, but still)