how to i18n static content

48 views
Skip to first unread message

Claudia Jürgen

unread,
Nov 28, 2011, 9:59:39 AM11/28/11
to bibap...@googlegroups.com
Hi all,

just wondered what would be the best way to i18n static content, i.e.
the stuff in public/

For files with a large amount of text like about, faq ... the message
catalogue is too cumbersome. These should be seperate files for each locale.

Apart from these any other static content might be changed due to i18n.
The most likely candidates are images, but changes in e.g. css files are
possible too.

Maybe this could be done via routes with one default public/ used as
fallback and a locale specific public/locale which contains only the
files to be internationlized.

So far I haven't found no best practice for this.

Claudia


--
Claudia Juergen
Universitaetsbibliothek Dortmund
Eldorado
0231/755-4043
https://eldorado.tu-dortmund.de/

Howard Ding

unread,
Dec 1, 2011, 11:32:10 AM12/1/11
to bibap...@googlegroups.com
Hi Claudia,

I think Rails has a way to handle static html files, but I need to check
into it.

I'm not sure that Rails provides a standard way to deal with it for css
and images. I'll check that as well. The css stuff shouldn't be too much
of a burden, as all of that would be accessed through helper methods
that would be easy to adjust. Images might be a bit harder as their urls
might be generated in a variety of places, but I do know that it is
possible as a previous application I did had different icons and images
depending on the locale. (Note here I'm talking about images native to
Bibapp of course, not user uploaded images and so forth. I don't even
want to think about that now.)

Howard

Howard Ding

unread,
Dec 1, 2011, 3:01:37 PM12/1/11
to bibap...@googlegroups.com
After a bit of searching and thinking, I'm not sure that Rails actually
does provide a good default way to handle this. In fact I think that if,
for example, you're trying to go to http://my-bibapp/faq.html then the
webserver sees that that file actually exists and the request never
actually makes it to Rails. So none of the i18n stuff there could kick in.

So probably you're right - what would have to happen is to put locale
specific directories in public and redo anything that generates a route
to one of them to take the locale into account when generating the link.
There shouldn't be anything hard about doing this, it'll just take a
little bit of time.

I'll put in an issue on github and try to get to it soon.

Howard

On 11/28/2011 8:59 AM, Claudia J�rgen wrote:

Howard Ding

unread,
Dec 1, 2011, 4:44:18 PM12/1/11
to bibap...@googlegroups.com
Hi,

I've pushed a change for the static html files. Instead of living in
public, the English ones now live in public/static/en. Those should be
translated as necessary for each locale.

Note that the 404/422/500.html error messages are not affected by this.
Assuming that Rails is working as it should these should be translated
directly in public to 404.de.html, etc.

I can do the images and stylesheets as well, although honestly I'd
prefer to wait until someone tells me they actually need that before I
do it. Claudia - if you need that now please feel free to tell me.

I suspect that some of the images in the the image directory are
actually not used by Bibapp at this time. But I don't know that for
sure. Some of the other images might profitably be removed from images
and an image from the icons directory used in their place (the ones that
are icons, of course).

Howard

On 11/28/2011 8:59 AM, Claudia J�rgen wrote:

Claudia Jürgen

unread,
Dec 2, 2011, 8:07:43 AM12/2/11
to bibap...@googlegroups.com
Hello Howard,

that's fine and I think this should be enough.

As for images and stylesheets I don't need them i18n, just kept them in
mind as possible candidates. The stylesheets might become important for
languages changing text direction.

Thanks again

Claudia

--

Howard Ding

unread,
Dec 2, 2011, 10:34:57 AM12/2/11
to bibap...@googlegroups.com
Certainly. I'm willing to do them when the need arises, but I think it's
better to wait until that actually happens. Plus I've been reading a bit
about Rails 3.1 and I'm not sure exactly how this problem would be
handled when I get around to that migration (not on my immediate
horizon, but I hope to do it sometime), so if possible I'd prefer to
postpone.

Howard

Reply all
Reply to author
Forward
0 new messages