Localizing code entry (was Re: Engage: Code entry screen)
Colin Clark
colinbdclark at gmail.com
Tue Feb 2 22:48:46 UTC 2010
Sveto, you totally rock. Thanks so much!
Tomorrow, the mission for Justin and me is to start integrating code that is in the incubator. Here's the order we're going to try to do it in:
1. Language selection (Yura and Michelle nearly have all the new data in both languages working)
2. Object code entry
3. My Collection
In the meantime, I'm wondering if you could help us with a huge favour. Can you take a look at some of the examples of how we've localized other components, and do the same for Object Code Entry?
Here's a brief description of how it's done, off the top of my head:
1. Message bundles are located in a directory parallel to the HTML template called "messages," and are named messages_[locale].json. For English strings, we've been putting them in the component's defaults rather than in a message bundle, just so something still appears even if an incorrect language is selected.
2. Markup feeds should locate the correct message bundle using fluid.kettle.getBundle(), passing in the render config and the query parameters. The markup feed should supply this to the component in the page's script block.
3. Templates shouldn't hard-code strings without using the Renderer. Any code that emits user-visible strings via the renderer should resolve messages via a message locator set to the component's strings option. ExhibitionView.js is probably a good example to see this in action.
Let me know if you have any questions. You're doing great work on these components!
Colin
On 2010-02-02, at 5:22 PM, Svetoslav Nedkov wrote:
> This was actually a bug that I was able to detect with some unit tests and it is now fixed. So the conclusion is that unit tests are a good thing. :)
---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org
More information about the fluid-work
mailing list