I couldn't really find an answer for this on the internet. I am currently developing a relatively big web application in Rails. And my locale file is growing rapidly.
My question is, does it matter if my locale file gets really big? If it doesn't matter, how does Rails handle this? If it does, what would be a good solution to this? I found in the rails documentations that you can name your files respectively to their language e.g. index.en.html.erb. But that would mean I'd have to edit each view for each language individually when a change has to be made.
Thanks!
Locales are loaded into memory when the server is started (not on every request). Rails handles all locales internally as one big nested hash. Therefore Rails does not care if there are one big or many small locale files.
What you need to consider: What works well for you. I had to work with an app with ~ 5000 locales once. I was very happy that they were organized into one folder for each language and splited into multiple files: One for every model or controller. The locales were clearly arranged and easy to find. Later we used a webservice to maintain the locales (webtranslateit.com) what also helped a lot when working with external (not technical) translators.
You can try to break up your locales file into separate files. More info:
http://guides.rubyonrails.org/i18n.html#organization-of-locale-files
Related
I'm setting up a new iOS project and wondering if I should use a Localizable.strings file to keep my strings even without planning to add support for other languages.
I've tried using struct to keep my strings before but I am wondering if this is a good practice. Using Localizable.strings will also work well on the library R.swift, another reason why I am struggling to choose a strategy.
There is no "best practice" in this case. There are practices and some may be a bit more appropriate for your case than others.
You are saying that you are not planning to add support for other languages but it seems like you want to be prepared for it if you change your mind. So first thing is to ask yourself what is the actual problem you are looking solution for. I would say the problem is the overhead you get once app is already out and you need to hunt all the strings you have used in your app and wrap them into NSLocalizedString. This usually includes endless testing and you will still in the end most likely forget to localize at least some strings.
You can from beginning start wrapping things into NSLocalizedString which will in the end help you extract all the strings using native tools from your code. The problem then are still Storyboards; not as much extracting strings from storyboard but removing those default texts you have no plan to translate (Like "Name" will actually be some name and should not be translated). So in my experience this is a half solution.
To solve the Storyboard issue there should be a tool (I can't remember which, maybe some other CocoaPod) which enables you to ignore views that should not be translated. So in this case you need to use 2 things; NSLocalizedString and ignoring untranslatable items in IB.
As you already put it nicely you can use R.Swift to get strings directly from your strings file. This is very neat but also extremely distracting as you develop. Doing so you are forcing developer to first enter a text in strings file before he can use it. Personally I hate that. Also this can be a problem with multiple developers being in conflict. Not to mention this hasn't nearly fixed your issue with Storyboards.
Creating a separate structure system to hold all the strings does work pretty nicely. You don't have to hunt down all of the strings in your code and you don't need to jump to strings file (going to another source is much more pleasant when developing since you can navigate to it very easily). You do also preserve a good structure, assuming you maintain it like label.text = Strings.Settings.User.firstNamePlaceholder which helps you to easily find strings you need or are deprecated. You can remove whole screens with great ease. But it still is an overhead for developer plus you still have an issue that now you need to drag all the outlets from storyboard to set the localized strings to them.
Doing this procedure you can in the end choose to use NSLocalizedString directly or to use R.Swift. In fact you can just use nothing and you will still not have much overtime switching to any of the two (again assuming that hunting down those strings in the code takes most of the time).
Personally I would go with nothing at all or go with creating a custom structure system which then uses nothing but just returns raw strings. But this all really depends on what size is your project of, what type of project, how many things are in Storyboards... It also depends on when you expect to have more resources so you either spend more time now and don't bother later or you simply do it simplest now prepare for a lot of work when localization is indeed needed (hopefully when that happens it is one of the "sweet" problems because it means you have tons of users).
I created a web-survey application using rails. The administrator specify each survey sections, questions, validations and possible answers/types of answers in yaml config files.
For now, I load the yaml config files for sections and questions at each request (on each page). I know I can use cache to optimize database queries, but would it be faster to use cache also for reading yaml config files? And what kind of cache would you suggest? memcache, binary file, other?
Thanks for any help on this issue!
I think Knuth said it best with...
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"
Unless its a problem, move on with your life. However to avoid being ranked down for snarkyness...
In this case, you could read your config files into Class constants to avoid File I/O when you need to retrieve the information if you really think it's going to be a problem.
However based upon your problem what you're probably trying to do could be done better with Backbone Forms but then you'd be adding complexity with JavaScript.
I would recommend not using yaml files actually, unless there is a very good reason for it. You should use your DB instead. It would be much more user friendly and easier to maintain if you used nested models with the correct associations. This railscast actually is almost identical to your situation.
I've been following a lot of good tutorials on building rails apps but I seem to be missing the whole specifying and validating db field sizes part. I love not needing to have to think about it when roughing out an app (I would have never done this with a PHP or ASP.net app). However, now that I'm ready to go to production, I think I might have done myself a disservice by not specifying field sizes as I went. My production db will be MySQL. What is the best practice here? Do I need to go through all of my migration files and specify sizes, update all the models with validation, and update all my form partial views with input max widths? or am I missing a critical step in my development process?
I think you're fine. Launching a web application is a process and the first step is to expose your app to the user and get the ball rolling. Refinements can follow. You are NOT fubared.
In general, i've NOT specified max field length's for each and every single field. Specify it only on those fields where it makes sense otherwise the default is good.
You're not making applications that come into play as a matter of life and death are you? If yes, then i'm not qualified to answer, i guess :)
My web site (on Linux servers) needs to support multiple languages.
What is the best practice to have/store multiple languages versions of the same site?
Some I can think of:
store in DB
different view file for each language
gettex
hard coded words in PHP files (like in phpBB)
With web sites, you really have several categories of content to consider for localization:
The article-type content elements that you would in many cases create, edit and publish in a CMS.
The smaller content blocks that are common to every page (or a sub-group of pages), such as tagline, blurb, text around a contact form, but also imported content such as a news ticker or ads and affiliate links. Some of these may only appear for one language (for example, if you don't offer some services in some regions, or don't have, say, language-appropriate imported content for a particular language: it can be better to remove an element rather than offering English to people who may not speak it).
The purely functional elements, like "Click here to comment", "More...", high-level navigation, etc., which are sometimes part of your template. Some of these may be inside images.
For 1. the main decision is using a CMS or not. If yes, you absolutely need to choose one that supports multiple languages. I'm not up-to-date with recent developments in PHP CMS's, but several of the Django CMS apps (Django-CMS-2, FeinCMS) support multi-language content. Don't forget that date stamps, for example, need to be localized, too (or you can get around this by choosing ISO dates, though that may not always be possible). If you don't use a CMS, and everything is in your HTML files, then gettext is the way to go, and keep the .mo files (and your offline .po files) in folders by language.
For 2. if you have a CMS with good multi-lingual support, get as much as possible inside the CMS. The reason is that these bits do change, and you want to edit your template as little as possible. If you write code yourself, think of ways of exporting all in-CMS strings per language, to hand them to translators. Otherwise, again, gettext. The main issue is that these elements may require hard-coding language-selection code (if $language = X display content1 ...)
For 3., if it's in your template, use gettext. For images, the per-language folders will come in handy, and for heaven's sake make choose images the generation of which can be automated, or you (or your graphic artist) will go mad with editing 100s of custom images with strings in languages you don't understand.
For both 2. and 3., abstracting from the language selection may help selecting the appropriate blocks or content directory (where localized images or .mo files are kept).
What you definitely want to avoid is keeping a pile of HTML files with extensive text content in them that would be a nightmare to maintain.
EDIT: Everything about gettext, .po and .mo files is in the GNU gettext manual (more than you ever wanted to know) or a slightly dated but friendlier tutorial. For PHP, there's are the PHP gettext functions, and also the Zend Locale documentation
I recommend using Zend_Translate's Gettext adapter which parses mo files. Very efficient + caching. Your calls would be like
echo $translation->_("Hello World");
Which would find the locale specific key for that specified string.
Check out i18n support for php: http://php-flp.sourceforge.net/getting_started_english.htm
We have several large products we'd like to integrate with a consistent localization strategy.
We're already doing the right things from a code point of view - ie. strings in resource files.
I'm looking for something that will organize localized strings in a database, and generate the appropriate resource files (ie. .RESX files for .NET, .js files, etc.) during the build process. Ideally, it would also be able to read in the files as well (detecting strings that have been added/removed).
The database would allow us to reuse translations in different products, switch to different technologies, and track what translations are missing in each release.
Has anyone found a good product that handles these requirements? What have others done to manage localized assets?
Found some good links in the answers for this question: Do you know of a good program for editing/translating resource (.rc) files?
There's a number of products which we're now evaluating:
http://www.lingobit.com/
http://www.sisulizer.com/
http://www.multilizer.com/
WinTrans - http://www.schaudin.com/
None of have quite the database-based approach we were initially looking for, but they seem to have the core functionality. Lingobit is an early favorite, but we haven't trialed in too much detail yet. Does anyone have a recommendation between those products (or similar)?
Check out GlobalSight or Alchemy's Catalyst
Catalyst is a standalone translation memory and localization engine that can be used in your build process (and is used by many large software companies). GlobalSight is a relatively new and open source translation database and workflow tool that looks very promising.