I think there are two aspects:
a) contractual milestones (for payment schedule)
b) milestones required within the overall development project plan - these may not be all tied to payment schedule, but if you have third party (or your own) dependencies that require that milestone is completed first, and want a very tight contract, you may look into building a some kind of penalty clause for failure to deliver on time (but be realistic on building up slack without telling subcontractor there is one, as almost every dev project overruns, the question is just how much for)
I am not clear whether you are looking to not to pay them (yet) for the milestone or the problem is that their delay causes you delay on other fronts so you want them first to complete System A before starting with System B.
I work with multilingual systems and from my experience you cannot really translate elements before the system is made pretty as the width of some element may result in a different translation phrase being required (original one may not fit later on).
<added>I also find useful to have defined tests I will run at the end of each milestone, so called "acceptance test", e.g.
- all navigation links lead to defined destination
- the layout as per mockup bar changes agreed in writing during the development phase
- functionality x performing y
This then tells exactly what you are expecting as a part of the milestone. Wording "system A completed" may mean different thing to different people.