1

At my company we have a web application that we have been developing for over 5 years. We still have a codebase that contains PHP4 and has been extended with loads of PHP5. The LOC is pretty big, about 471k. It is not based on a framework, ORM, etc, etc.

The developers who started of with this project ignored any i18n and translations. All the language texts are hardcoded in the software. Yes, I know this sucks big time. At the moment we're fine since we only sell this in the language the software is written in but we're also looking at expanding abroad.

I'm struggling with the best approach on dealing with the translation. How would you guys approach this? Would it be better to rewrite using a framework since that would probably also improve the codebase and providing a solid structure. Or would you just use the current software and filter out the language texts.

Any tips and hints on this subject are appreciated!

tomvo
  • 1,409
  • 1
  • 12
  • 21
  • I guess all answers help me in deciding what to do next. Do I still need to accept an answer? – tomvo Jan 09 '12 at 14:21

5 Answers5

2

I think both variants are possible. You can leave your code, or rewrite. But as you know rewriting is a long process, in spite of that fact you've writing it for over 5 year.

If it's still stable, works fine, and PHP4 and other 'tasty things' you don't need, you can leave and just review all hardcoded texts. i18n helpers are very easy to make. You have to do nothing more then:

  • Choose appropriate way of storing texts and translations
  • Caching mechanism for already loaded translations
  • Class and helper for i18n operations.

You should analyse you bussiness plan well, if you decide to rewrite you code.

devdRew
  • 4,393
  • 3
  • 24
  • 33
  • This is also a comment to all answers, I guess part of my problem is also the frustration of dealing with legacy when you see so many new great stuff showing up around you in developer world. It makes you want to throw it all away and start from scratch. – tomvo Jan 04 '12 at 19:10
  • We all face that, but you have to put on your business partner hat and say "What's best for the business?" Development is rarely focused on using all the shiny new toys we have available to us. It's about getting the job done in an effective and cost-efficient manor. – Jonathan M Jan 05 '12 at 18:33
1

Still got an additional answer. Translating almost identical strings is very costly. Multiply that with the number of languages and one realizes: a good internationalization with sharing of same strings, and maybe formats, is really more efficient.

A first rewrite of the templating part, probably makes sense. First by hand, then with an automatic conversion tool written by you. It should prepare I18N.

Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
  • What if I would say roughly 50% of the PHP code generates HTML and there are no templates? – tomvo Jan 04 '12 at 15:28
  • I just know how you feel; much experience with legacy code. But you at least have to convert HTML to components (like ` – Joop Eggen Jan 04 '12 at 16:15
1

In my experience, it's not a good job to have a single project with two major goals - especially if those goals are almost entirely unrelated from a business point of view. I'd have one project team responsible for localization (which may well involve more than just translation - different countries have different legal requirements, currencies, payment providers, etc.), and one team for "improving the code base".

I'd start by having the localization team work out a rough plan (and cost) for "the simplest thing you could do" - retro-fitting localization functionality into the site as it is right now. Unless that cost is unacceptable form a business point of view - I'd go down that route.

If the business case for refactoring hasn't been made, I'd not try to shoe-horn it into your localization project - I've seen similar things happen before, and all the developers wanted to work on the cool refactoring stuff, talk about the relative merits of various frameworks, and which source code control system to use, while the thing the business cared about was pushed to the future; eventually, the business owners lost interest in the project, and cancelled it.

If there really is no realistic way to do the localization without a refactoring effort, I'd still run it with two, separate teams. The localization team can be a primary requirements owner for the refactoring team, and they do need to work together - but by keeping the two projects running independently, you avoid the risk that you get 90% of the refactoring done, but only 10% of the localization.

Neville Kuyt
  • 29,247
  • 1
  • 37
  • 52
0

It sounds like you have more than a translation project ahead of you. If you're wanting to take it abroad, you'll have to redesign at least part of the system.

If your budget allows for it and the benefit justifies it, you'll want to step back and take a look at the overall design. Keep what you can, but don't be afraid to rip out, redesign, replace and upgrade major portions of it.

Much has changed in the last 5 years, so if it's an app that you plan on selling for many more years, it's likely worth the investment in redesign.

Jonathan M
  • 17,145
  • 9
  • 58
  • 91
  • True. I guess I'll also take the business plan comment from devdRew into account. Also, it's pretty hard to foresee the impact/time of the rewrite of a 5 year legacy product when you use modern frameworks instead. – tomvo Jan 04 '12 at 19:13
  • Break into modules and evaluate each one. They likely don't all need rewriting. Determining the cost/effort impact of a module rewrite is simpler than doing it for a whole system. – Jonathan M Jan 05 '12 at 18:31
0

It depends on what the priorities are, as to what you should do.

If the main concern is the language translation, then you can start with just taking out the hard-coded strings so they can be internationalized.

If there are other needs, such as wanting to easily support different databases, then that would help determine if there is a better approach.

James Black
  • 41,583
  • 10
  • 86
  • 166