Using shorter i18n keys (e.g. t '.submit_button') in Rails views makes them easier to type, but is it actually good? When later you decide to refactor your views and partials you have to remember to update the respective localization entries. Wouldn't it be more robust to name them by their business meaning and always specify the full key-name?
Well, I'm using a mixture. ;-)
For things like "yes", "no", "submit", "cancel" I tend to use a namespace called "defaults" so I always use it like t 'defaults.cancel'. That could also address the "submit_button" thing you mentioned above.
For my specific views I decided to use the lazy lookup feature.
If you want I18n keys for specific views you have to decide what fits best for you:
If you don't mind searching your yaml file for the I18n keys and
change them if you change the view do so. The advantage is that you
save some characters for each I18n.t call of it in your view.
But if you change your view names very often (not sure why you should
have to do so :) ) then you might be better of using the way you described.
As I already said I prefer the first option since it's more convenient for me.
Related
I have a Grails application that needs internationalization. Grails makes it easy to translate fixed strings using the messages.properties file, but I could not find how to translate model fields.
Is there some way to manage internationalized models, so that models in multiple languages can be entered in some admin area and the correct one will be selected in the view?
I could roll up my own system, but maybe something of this kind already exists and it is more featured and battle-tested than what I would write. This had happened to me in Django: I used a custom system - which I describe below - for internationalization, only to find out that various Django apps already solve this problem.
An example of how to solve this issue
If it is not clear what I am trying to achieve, here I describe the implementation I used on Django.
I had two base abstract models, I18NModel and TranslationModel. The actual models used in the application inherited from the former, while their translations from the latter. In inheriting, they needed to define a foreign key to their untranslated model and to define a field with the associated language.
The original model, in turn, inherited a method translate, that took a language and returned a proxy model. This proxy had a reference both to the original, untranslated model and to a translated model associated to the correct item and language.
Whenever you asked for a field on the proxy, it would try to find if it was defined on the translated model. If it was, it would return that, otherwise it would give as default the field on the untranslated model.
Hooking it with a method to find the current language, I got as a result something that I could use like this in the templates:
<h1>{{ article.translate.title }}</h1>
while allowing editors to insert translations in the admin area.
Looks like i18n-fields plugin does the thing.
This is a new application, and I have an index method on a Search controller. This also serves as the home page for the application, and I'm trying to decide if I am headed down the wrong path from a design pattern perspective.
The method is already 35 lines long. Here is what the method does:
3 lines of setting variables to determine what "level" of hierarchical data is being searched.
Another 10 lines to populate some view variables based on whether a subdomain was in the request or not.
A 10 line section to redirect to one of two pages based on:
1) If the user does not have access, and is signed in, and has not yet requested access, tell them "click here to request access to this brand".
2) If the user does not have access, is signed in, and has already requested access, tell them "so and so is reviewing your request".
Another 10 lines to build the dynamic arel.
I can't get it straight in my head how to separate these concerns, or even if they should be separated. I appreciate any help you can offer!
Summarizing what you've said in something codelike (sorry, don't know ruby; consider it pseudocode):
void index() {
establishHierarchyLevel();
if (requestIncludedSubdomain())
fillSubdomainFields();
else
fillNonsubdomainFields();
if (user.isSignedIn() && !user.hasAccess()) {
if (user.hasRequestedAccess())
letUserIn();
else
adviseUserOfRequestUnderReview();
}
buildDynamicArelWhateverThatIs();
}
14 lines instead of 35 (of course, the bodies of the extracted methods will lengthen the overall code, but you can look at this and know what it's doing). Is it worth doing? That really depends on whether it's clearer to you or subsequent programmers. My guess is it's worth doing, that splitting out little code blocks into their own method will make the code easier to maintain.
That's a lot of variables being set. Maybe this is a good opportunity for a module of some kind? Perhaps your module can make a lot of these decisions for you, as well as acting as a wrapper for a lot of these variables. Sorry I don't have a more specific answer.
Without your code it's somewhat difficult to suggest actual fixes, but it definitely sounds like a really wrong approach and that you're making things much harder than they need to be:
3 lines of setting variables to
determine what "level" of hierarchical
data is being searched
if there is a search form, I would think you would want to pass those straight from the params hash into scopes or Model.where() calls. Setup scopes on your model as appropriate.
Another 10 lines to populate some view variables based on whether a subdomain was in the request or not.
This seems to me like it should be at most 1 line. or that in your view, you should use if statements to change what you'd like your output to be depending on your subdomain.
A 10 line section to redirect to one of two pages based on:
the only thing different in your explanation of the 2 views is "whether the user has requested access" surely this is just a boolean variable? You only need 1 view. Wrap the differences into 2 partials and then in your view and write one if statement to choose between them.
Another 10 lines to build the dynamic arel.
It might be necessary to go into Arel, but I highly highly doubt it. Your actual search call can in most cases (and should aim to be) 1 line, done through the standard ActiveRecord query interface. You want to setup strong scopes in your models that take care of joining to other models/narrowing conditions, etc. through the ActiveRecord Query interface.
I want to have Greek support in my rails app for the messages/flashes etc. I took a quick look at the I18n framework but it seems like a lot of configuration for something so simple. I thing that there should be a very easy way to do something like this but ( apparently ) I don't know it. If anyone would be willing to help me I'll be glad. Thanks.
Rails has conventions so you don't have to configure.
Create a file in config/locales/el.yml with the contents:
el:
flash_messages:
success: "επιτυχία"
fail: "αποτυγχάνουν"
Then in your controller:
flash[:notice] = t('flash_messages.success')
and you'll get the translated string in your view.
You can change the locale like this:
I18n.locale = :el
I don't know how it could be easier. The "Rails I18n Guide":http://guides.rubyonrails.org/i18n.html has all the gory details if you want to fight the conventions or go beyond simple.
I18N ain't simple.
Here are some of the reasons why internationalization is hard.
First, every piece of text that might be shown to the user is a potential candidate for translation. That means not just properties of components (like menu items and button labels), but also text drawn with stroke drawing calls, and text embedded in pixel images (like this one taken from the MIT EECS web page). Translation can easily change the size or aspect ratio of the text; German labels tend to be much longer than English ones, for example.
Error messages also need to be translated, of course — which is another reason not to expose internal system names in error messages. An English-reading user might be able to figure out what FileNotFoundException means, but it won’t internationalize well.
Don't know Ruby so I can't help you more.
What's the best way to implement an interface that looks like this in rails?
Currently I'm using Searchlogic, and it's a tad painful. Problems include:
Making sure certain operations remain orthogonal -- for example, if you select "Short Posts" and then search, your search results should be restricted to short posts.
Making sure the correct link gets the "selected" class. Right now the links are <a>'s, so maintaining this state client-side is tricky. I'm hacking it by having the AJAX response to, say, sorting return a new sort links section with the correct link "selected". Using radio buttons instead of <a> tags would make it easier to maintain state client-side -- maybe I should do that?
I recently solved a similar problem using named_scopes and some ruby metaprogramming that I rolled up into a plugin called find_by_filter.
find_by_filter accepts a hash of scope
names and values, and chains them into
parametised scope calls. If the model has a named_scope that matches the provided name, this is called.If no named_scope is found, an anonymous scope is created.
Why is this:
http://MySite.com/Project/24/Search/32/Edit/49
preferred over this?
http://MySite.com/Project/24?Search=32&Edit=49
I'm not sure where your premise is coming from? It looks like an artificial example, which makes it hard to comment on.
A better comparison would be something like:
http://MySite.com/Project/24/Members/Edit
As opposed to:
http://MySite.com/Projects.aspx?id=24§ion=Members&action=Edit
Where, among other things, the hierarchy of entities is immediately obvious from the first example (ie, a Project contains Members). It also suggests that you can use other URLs that contain similar structures to the first (ie, /Projects/24 and /Projects/24/Members), so in that sense it's more concise.
If it comes down to actions that have a variable number of parameters, such as searching, then it's totally fine to use URL parameters as this will give you more flexibility, eg:
http://MySite.com/Projects/Search?name=KillerApp&type=NET
You could construct a URL using the first style, but you don't really gain anything, and managing the route could add unnecessary overhead:
http://MySite.com/Projects/Search/name/KillerApp/type/NET
I would argue that this (or any similar construction, eg if you removed the param names) suffers from an artificial hierarchy - the action in this case is really Search, and everything else is just a parameter of the Search, so it's in the same hierarchy, not some "sub" hierarchy.
Not really a fair comparison. The style allows you to drop the GET parameter names, so the routed one should read something like
http://MySite.com/Project/24/32/49
It's really an aesthetic improvement, though -- it's both neater-looking, and easier to type or read out to someone.
Its mostly a human readability issue, although (since most search engine ranking algorithms are not publically disclosed), it is believed to have SEO value as well.
In the example case, it may not be any better. But it's a Search Engine Optimization in general. Here are some SEO best practices -- from that article ...
Ideally, the URL structures should be
static, and reveal what the page is
about. A simple and clear URL
structure is much easier for both
search engine spiders and human
beings.
Easier to remember as well. It's easier for a user to remember /Employee/1 to get the information for employee #1 rather than understand a querystring. Not a reason to use it but I think its a small improvement.