Well, sounds like the problem is you don't have any potential users on board yet. But you could alienate some potential customers if it really sucks erm is not polished yet. Some options you have might be to find other people in-house who could simulate those users, find customers who have a stake in codeveloping with you over a significant period, write up scenarios of your own and hand it to your mom, or even hire a professional. You need a useability study done and it sounds like you are really not at alpha stage yet. You need honest help without any threats to the project. It would have been easier if people interviewed for planning the spec were still involved, did you spec it yourself? Maybe sales people could get involved? Of course I don't expect you have a budget, or want to admit to management the need, but for example I'm experienced in designing services, doing useability studies, interviewing future users, am also a professional translator, and also work with a large translation company that could use the service as customer or translator supplier (though we are mainly Japanese, Chinese, Korean, English, so this is really just hypothetical for you). If you have someone or a few people who can assemble those capabilities in one room then you can start to attack the problem efficiently. For starters, anybody not on the coding team (which already knows the system too well) is a potential partner on this. So if you have a pool of translators at your company like we do, try and get some to help. Maybe even you could offer compensation. When it gets launched you are bound to find useability issues you didn't realize (beyond even the straight functionality you designed in) and you need to get some allies with the viewpoints of the users otherwise you may have a showstopper show up late in the game.

My guess is the first thing you could try is find a junior member of the translation and sales departments and ask them for some time. If they can join your team for alpha and beta testing then you will be far ahead. Finally, you can offer customers that get involved a chance to help direct development and add their own feedback to make sure it is something they want. This may be of value to them enough to spend the time to help you, but you will have to be sure to document everything you get them to tell you and make sure future development and testing is handling those issues.

Finally I could make a couple concrete suggestions. Make sure there is a form for writing up bugs, testing issues, whatever you call them. If you see something that can't be easily reproduced at least try to get it well documented. If it is really a communication/responsibility problem then get everybody on the team in a room with a terminal (and projector if you can), and go through it with them. They won't agree with you on useability issues probably but will jump out of their seats if you show a subtle bug. also, you should get the testers into a room under your control, provide them with instructions on how to test and write up reports, and even sit with them (or videotape them) if you must. the scary thing about no feedback is that it probably means nobody will use the system, and/or there is a major design (could be just graphic design!) problem which makes it confusing to use. if you find people who are honest and helpful they may even say "well we wouldn't ever really use this", or some such thing. maybe not to your face but.. so i'd advise you to press for feedback to you and try to get the bad news as soon as you can. it may also be an organizational problem, i can say for sure that one ad agency i audited had according to the ceo spent 3 million bucks on systems that were seldom used. some systems were badly managed in other countries, or dead due to lack of an organizational structure to run it frequently and ensure involvement. but some systems were indeed used by people, though management did not know this. When you get people to pass around a report form, or you get people in a division meeting, generally they don't respond significantly (though this can be cultural I guess). So if you can make a more casual, interesting atmosphere by say asking people directly to help you out on a little problem, it may provide more feedback than you are getting now.

Anyway these are just my input on where you can go from here. I don't think it sounds like you are really ready to go full beta with customers. Probably you need to first get the developers all to sit at the same table and take responsibility for your uneasiness with the project, then form an alpha testing group, and do periodic testing until you get to beta which you do first in-house. One system I know that works very well was developed by a computer manufacturer to work with their ad agency, and both sides were involved which ensured it answered real needs well. If you can create that plus a responsive development team it might save the day.