If you localize for a number of languages and have lots of content, how do you keep any changes in sync? For example, a bird app that list various birds (200 of them). If you have chosen to localize for five languages, that means you need 1000 localization files. Not only is it a lot of initial translating but very time consuming to keep up if any of the bird entries change.
Is there a better way to sync everything and do the initial translations?
Like gmagana said, you should only need 5 files (one Localizeable.strings for each language).
See the Apple guide "International Programming Topics," specifically the section called "Strings Files."
This sounds more like a process management issue than a tools issue. At the heart of the problem is the fact that the strings files are language centric, but the translations you're managing are data centric. Tools can help maintain data integrity, but ultimately it'll be fixed with process.
The process you're looking for is either a mechanism to keep them in sync or a way to mark the other four as out-of-sync. The best process will be simple to implement, easy to understand how it works, obviously note out-of-date entries and lend itself to an automated check. Getting all four -- simple, easy, obvious, automated -- is not an easy task.
There are a few ways you and your team can handle this.
One is to not allow a commit that doesn't change all five strings files. A commit-hook script can enforce this in the repository. This falls apart when there is no change to the other translations, such as when fixing the spelling or grammar in one language.
Another is to file four follow-up bugs whenever one translation is changed and make sure they get done in a timely manner. This falls apart when two or more changes are made to one entry before the first set of four follow-up bugs are closed. Either the translators will get annoyed with extra bugs they have to triage or, worse yet, they'll address the bugs out of order and in the end set the translation to the first bug's version of the entry, not the most recent version.
A third is to only make changes to one language. After the code for the next release is finished, run a diff against the last release (e.g., svn diff -r <last release>) and use that output as a list of translations to complete on Translation Day before cutting the new release. Personally, I don't think this method makes the out-of-date translations sufficiently obvious. It's too easy to cut a release without updating the translations and simply not notice they were forgotten.
A fourth option that will be more obvious is to prefix the translation in the other four with "REDO:" whenever a change is made to one. Before cutting a release, search for and clean out the REDO entries. This method carries two risks: REDO labels may be forgotten on a commit, or a release could be cut with embarrassing REDO labels still in the strings files.
For all of these, the pre-commit peer review should check the chosen process was followed. "Many Eyes Verify," or so they say.
I'm sure there are other ways and there is no clear "right answer" here. It would be good to have a team discussion to determine the best method for the team.