http://sourceforge.net/projects/rthree

It has support for the generic “contexts” you talk about, but they are called “intls” there, although they should really be called “variations”.

How would you use the service classes (or whatever would it be)? Passing context and tag? then context would be growing and growing and translation service with it.

I would employ simpler solution, keep the decision of which text to show in business logic as it is closes to the source of what should be shown (at least more or less what you want to show) and then in translation service just find the correct string for it depending on locale. All you pass is locale (lets say language and country). Or you can even keep it in the service static variable and set it during bootstrap or something.

View would just show the populated string.

Artur

admin :
How would you implement support for the contexts as described? Please bear in mind that it’s not necessarily corporate vs residential, and perhaps that was a poor example chosen by me. User vs admin is perhaps better. The two different contexts will share 90%+ of the translated texts, hence splitting them is not a good approach in my opinion.

I don’t know the specifics of your application, but usually different levels of users are presented with different interfaces, like admin control panel vs user interface. This is definitely true for the application I’m currently working on, but I understand that it may not be the case for your product. We have separate admin and user interface, but both use the same translation mechanism in view scripts, like this:

<h1><?=$this->translate(Message::LOGIN)?></h1>

Since translations are stored independently of view scripts, we can reuse translations in different view scripts without problems. The only thing to note is that translations should be logically complete chunks of text, therefore some templating support (even if it’s the most basic one, such as offered by MessageFormater class from pecl/intl extension) should be provided.

If application required single interface for different levels of users I would go for using several view scripts and choose appropriate view in controller based on user level.

I agree that there are quite a number of features when it comes to formatting (currency etc) that’s not covered there, and I’ll update the post to cover those topics later on.

How would you implement support for the contexts as described? Please bear in mind that it’s not necessarily corporate vs residential, and perhaps that was a poor example chosen by me. User vs admin is perhaps better. The two different contexts will share 90%+ of the translated texts, hence splitting them is not a good approach in my opinion.

Besides, you missed many more features required for real internationalization, like formatting numbers and dates, handling text direction, different measurement systems (imperial vs. metric), etc.