The sooner the developers can get code to the testers, the less the risk of back-loading the sprint.
There are a number of things the team can do to help with this.
Minimise the size of stories. The smaller they are, the earlier in the sprint there will be completed stories and the sooner the manual testers will be able to get started.
Plan carefully. Focus in the planning meeting on what order of stories will best keep the manual testers busy. Perhaps there are certain stories that require a lot more testing than others? These stories should be worked on first and if possible broken up so that they are delivered sooner.
Work through each story in turn and decide what is practical to develop and test in the sprint. It may be that some combinations of stories are just not practical, especially if they are all manual testing heavy.
Try and leave the sprint planning session with an idea of what will get done and when. Of course this won't be perfect, as unexpected things will happen once work has started. But you will find there is real value in spending time during planning so that these problems are minimised.
In the medium/long-run you might want to consider having the manual testers cross-train to learn how to do automated testing. This will give you more flexibility and enable you to generate more automated regression tests. It would also help if the developers were willing to assist with testing. This would allow you to reduce the elapsed time for the manual testing.
Finally, if you still have the issue of incomplete stories at the end of the sprint (as they have not been tested), then the team should start to bring fewer story points in to the sprint. Better to have the team working on a realistic amount of story points than to have them continually missing the completetion of some stories.