Hacker News Reader

Comment by nathell | Hacker News Reader

Any support for i18n?

(For English-only speakers: Excel's translation to other languages goes as far as translating function names, thus rendering non-English Excel users' knowledge useless when confronted with an English Excel. E.g., IF(ROUND(A1)=1,B1,C1) in English Excel is JEŻELI(ZAOKR.DO.CAŁK(A1)=1,B1,C1) in Polish Excel -- yes, with all those funky non-ASCII letters.)

View on HN

That's the reason I always use the English version of Office. But then it's so weird when I go help some colleague and they're using the local version, and I'm suddenly a beginner... A remainder of the old world in today's hyper-globalized world.

And it makes auto completion useless. You type 'SU' and stare the screen "WTF?". Oh, this Excel is in PT-BR! 'SOMA'

And they even change conventions. "SUMIF" must be "SOMASE", right? Wrong, in PT there's a "." between words, so it's "SOMA.SE"...

Not only PT, that happens in most languages where the dot is not the decimal separator. It might have been the case in English as well if they used commas.

That's the reason I always use the English version of everything. What I find most ridiculous is when hotkeys get translated, ex. Ctrl+S is Underline in Spanish (Subrayar)

It never occurred to me that other languages would have different hot-keys. Intuitively it makes sense, but damn I imagine a lot of programs don't do it so it must be a horribly inconsistent experience (I get angry when a program fails to support something like CTRL-W to close windows or CTRL-A for select all or the inconsistency between some using ctrl-shift-Z or ctrl-Y for redo).

I guess that's the advantage to the old Word Perfect approach of function-keys for everything (provided you have one of those nifty overlays that show you all the key-commands).

This also includes changing argument separators according to the locale. In France, for instance, where commas are used as decimal separators, function arguments must be separated by semicolons. Faithful i18n should take both into account.

Luckily this is a UI thing and the files themself normalize to English. So the project could still be useful for opening Excel files on the web (theoretically).

Oooh, so if I make a spanish excel file and open it in an english excel, the function names are all translated?

That's actually pretty neat. Power of storing your equations in a binary format instead of plain text, I guess.

As far as I know it's still text, but the function names are stored in English and are only localised within the Excel UI.

Fun fact: Some old versions of Excel even had a localised VBA ... using ZeichenF instead of String and other oddities made that a very weird experience.

Every time I read some comment about how people shouldn't use excel for complex calculations and should use relational databases or Python or whatever else, I'll know why it will never happen.

It's really easy to implement the easy parts of spreadsheets, getting the hard parts right is why Excel continues to dominate the space.

There is a good reason why no one has unseated excel: it's easy to build the really easy 80%, but the last 20% is incredibly difficult and time consuming.

It's a shame Scheme in a grid appears to be abandoned (if anyone manages to build it under, say, the latest Debian Stable, please let me know):

http://siag.nu/siag/

Ironically, Excel fails miserably at implementing the easy parts of a database.

Seriously, how much does doing a simple "Select Distinct" suck in Excel?

So much that I wrote this: http://scpike.com/uniqify/

(I know you can do filter => unique only => copy somewhere) but it's stupidly slow.

Either way, filters aren't a solution if you're constructing a reusable spreadsheet that somebody else is populating.

Most spreadsheets I've dealt with don't hold relational data. Are there people who use them as such? Sure. But I don't think that's the typical use case.

I would say relational data is the dominant use case for spreadsheets. It's a natural fit given the rows and columns. What other kind of data do you see in spreadsheets? Hierarchical data is not a great fit for spreadsheets.

It provides a set of JavaScript functions. It doesn't try to parse formulas. You probably could go back and define aliases for each function

Reply on news.ycombinator.com