Menu

#7 Internationalization is broken

open
nobody
None
6
2009-04-17
2009-04-17
No

There is basically no proper internationalization currently, neither in the front end (both RoR and PHP) nor in the back end.

According to popular believe, translations into several languages are said to be available (the bug reporter has a bulgarian language file available) but it's pretty unclear for what those files would be; only front-end or also backend.

Logging in as an Administrator and clicking on "Globalize" leads to nothing but an error message.

Discussion

  • Vidul Nikolaev Petrov

    During the migration process from RoR 1.1.6 to 2.3.2 the internationalization is removed. It will be added after this step. The question about the place - only front-end or also backend - both, because most strings are defined in the templates (views), but there are also strings in the controllers (the case when a method should return a text, like in Ajax call).

     
  • Torsten Schlabach

    IMO i18n should be both in the front end as well as in the backend.
    In the front-end it will be most important as this will be used by the user's users.
    When we talk about the front-end, keep in mind, it's not only the RoR but also the PHP client.
    Any strings which are like tokens should not be localized.

     
  • Vidul Nikolaev Petrov

    About PHP - no idea (I can check what's necessary).

    Please let me know what means "token" in this context, is it the common terms like "login", "account", etc.?

     
  • Nobody/Anonymous

    > Please let me know what means "token" in this context

    Any technical parameters where the data type is "String". I have no idea if there are any.

    Another way of phrasing that: A client localized in any language needs to be able to talk to any server.

    One very typical way of breaking that would be the Submit button of a form, if you don't separate name and value, for example!

    But I had parameters exchanged through SOAP in mind primarily.

     

Log in to post a comment.