markdown internationalization in nbviewer

[druedaplata]

is it possible to display correctly spanish letters such as [ñ, á, é, í, ó, ú] in a notebook I pass to nbviewer?

[Carreau]

As far as I can tell it works fine already : http://nbviewer.ipython.org/gist/Carreau/1757899baeac304a28f3

[druedaplata]

it happens when a cell is in markdown

[Carreau]

The example I link above has both a code cell and a markdown cell, which both works. . Why not linking to a failing example ?

[druedaplata]

here is one it's supposed to say "El niño está ahí"

[Carreau]

Ah! It's a bitbucket specific issue !
Same notebook on github gist.

Will see what we can do.

[willingc]

Thanks @sandiego206 for the link.

@Carreau I made a gist (https://gist.github.com/willingc/5de6a2d7aeebde35ccc8) for the example that @sandiego206 has on bitbucket. If I enter that gist URL into nbviewer, it renders correctly.

I actually think this may be a bitbucket issue. Looking at the example @sandiego206 posted, the URL from the nbviewer page is http://nbviewer.ipython.org/urls/bitbucket.org/sandiego206/asdasd/raw/master/Untitled.ipynb

Working backwards, I am guessing that the URL that was entered into nbviewer was https://bitbucket.org/sandiego206/asdasd/raw/master/Untitled.ipynb. Putting that link in my Chrome browser, pulls up the following screenshot:

Looking at this screenshot, the letters are incorrectly displayed in BitBucket source. Also put in my repo on Bitbucket https://bitbucket.org/willingc/testrepo/src/bf6da58eedb00cfc208f9640605c4cfe0c63ec08/mytest.ipynb?at=master&fileviewer=file-view-default Same results as @sandiego206

@Carreau just saw your post as I was about ready to hit the comment button.

[Carreau]

@willingc no problem, we get to the same conclusion.

Bitbucket is leaving the encoding unknown which lead most browser/api to decode as Latin-1, if you force utf-8 it works:

SHouldn't be too hard to fix :-)

[bollwyvl]

Here's some info, arriving at the same reason as @Carreau and @willingc.

So the size is different by one byte (whitespace), and github specifies a charset in Content-Type.

Thing is, we try to figure out the incoming content type, but looks like if it's text.* (and no charset), we default to ISO-8859-1.

However, we know that a notebook should/must be UTF-8, so perhaps whenever we are trying to fetch a notebook, we just force UTF-8?

[minrk]

Knowing that a notebook on-disk when written by our software is utf8 doesn't mean that a webserver will always serve it as utf8, especially when the upload may happen through a text form. But I agree that we should probably use utf8 as the default. We should keep in mind that the encoding detection code is verbatim from requests, so if we ever use requests to fetch notebooks, it will restore the current behavior.

[bollwyvl]

That's the issue with bb, i think... They serve it as utf-8, but don't
declare any encoding... I don't think Latin-1 is any kind of http default,
we just decide to fall back to it if they don't specify an encoding and
"text" appears in content-type. I'll have to look into why that choice was
made... And what it might break!

On 04:26, Mon, Sep 28, 2015 Min RK [email protected] wrote:

Knowing that a notebook on-disk when written by our software is utf8
doesn't mean that a webserver will always serve it as utf8, especially when
the upload may happen through a text form. But I agree that we should
probably use utf8 as the default. We should keep in mind that the encoding
detection code is verbatim from requests, so if we ever use requests to
fetch notebooks, it will restore the current behavior.

—
Reply to this email directly or view it on GitHub
#507 (comment).

[rgbkrk]

@mark-adams - maybe something you could chase on the BitBucket side?

[bollwyvl]

In the meanwhile, the reference url now renders properly:
http://nbviewer.ipython.org/urls/bitbucket.org/sandiego206/asdasd/raw/master/Untitled.ipynb

Closing!

[rgbkrk]

Oh gosh, the menu bar rollup is quirky on Chrome.

[bollwyvl]

How so?

[rgbkrk]

Sometimes the header scrolls up and sometimes it doesn't. The animation speed has this weird cognitive disconnect for me, where it's not the same time as me scrolling and has a very controlled animation delay. This could just be me not liking it and I really don't have anything more constructive to say. Love all of this, it's the only thing (even on the old site) that triggered a tilted head from me.

[willingc]

@bollwyvl @rgbkrk Is this how the example is supposed to look on Chrome? It no longer looks like a notebook to me, but just floating text.

[willingc]

Agree with @rgbkrk that the scrolling behavior is a bit wonky on Chrome. Sometimes it redraws a line under the top menu, sometimes it doesn't.

[bollwyvl]

That notebook contains one markdown cell, with one line of text in it. I guess the big deal is that we dropped the drop shadow around the notebook border? I can be argued into putting it back, but, as with the little grey line when scrolling, I'm trying to match the overall jupyter.org branding.

And cheers to fixing the scrolling stuff. Headroom is annoying anyway! What do we want? Any insight @cameronoelsen?

[willingc]

Fair enough on the little grey line. I guess what I find more disorienting, from an end user perspective (especially a non-technical one), is that visual clues of the source and topic of the notebook are not provided or inconsistent depending on where in the folder structure the notebook exists.

A notebook with missing title in first notebook cell
The end user is left guessing the notebook's subject and source.

A notebook with a title in first notebook cell
Although the end user doesn't have a quick view to the source of the notebook, the end user knows the subject due to the author's entry in the first cell.

A notebook with a grey bar displaying where in the tree the notebook exists
The grey bar would be a helpful addition when notebooks are displayed initially, especially those notebooks that do not have a title in the first cell.

[bollwyvl]

I really appreciate the feedback. In some sense, I have been looking at the site too long, and am averse to doing really significant things to avoid breaking some expectation.

In the case of your first example, the gist provider, I can see how we could get some nice context in there: <user> / <gist> / <file>.

In the case of a raw URL, we could at least show the requested filename.ipynb. I don't think we can do much more, as we don't render arbitrary file listings... i suppose one could show the breadcrumbs of the deconstructed URL, but they wouldn't be clickable.... and in some cases they would be awful (dropbox, etc). and the URL itself wouldn't reliably be something you could visit either.

It is one of my sadnesses (#437) that we don't have a consistent metadata approach for things like title and author, but it's hard to steer that ship.

I'll open new tickets for these items so we can put this one to bed :)

[willingc]

@bollwyvl Sounds like a good plan to me. Thanks 🐱

[rgbkrk]

It is one of my sadnesses (#437) that we don't have a consistent metadata approach for things like title and author, but it's hard to steer that ship.

I respectfully argue that you fight the good fight.