It's generally recognised that, in Scrum at least, the maximum practical team size is 9. A team of 12 people is uncomfortably large and would indicate a need to refactor into smaller teams. The Scrum Guide puts the minimum team size at 3, so (in theory at least) you could get as many as 4 new teams out of the one you already have.
Furthermore, Scrum only recognises 3 roles - the ScrumMaster, the Product Owner, and the Development Team. In Scrum you don't have separate QA testers, UX people, designers, BA's and coders. The Development Team is meant to be cross-functional and multi-skilled, and there aren't supposed to be any "skill silos" where people only do a particular job. Those silos are an invitation for team members to be waiting on each other instead of "going to where the work is" and getting the work done. In Agile terms skill silos are a type of waste, and one that needs to be optimised away by cross-training.
Now, that's all fine and good as far as Scrum theory goes. In practice though a great many...perhaps even most...organisations will merrily break these rules. In my experience it's very common (I would say normal) for a separate and distinct QA or tester role to be included in an Agile team. Separate BA's are also very common. Why? Because it is recognised across industry that Testing and Business Analysis are valid careers in their own right. All you have to do is to look at the jobs boards to confirm that. There are plenty of positions advertised for Testers and BA's, and for which some sort of "agile experience" is required. I'll leave you to work out how many of those organisations would *claim* to be following Scrum.
So the project you have described breaks Scrum rules, but if it is any consolation I certainly recognise the situation you are in. The question is, what can you do about it?
Breaking down those silos by cross-training all 12 people would be a huge challenge. Not only would it mean training QA experts to be developers, it would also require PHP developers to be Ruby programmers, vice-versa and contrariwise. It would be fantastic if you could get buy-in for all that, but the short to medium term hit would be huge, and the individuals concerned might not have the appetite to stray so far from their comfort zones.
But perhaps it would be possible to "box clever" and temper cross-skilling with some refactoring into 2 or 3 smaller development teams. Those development teams would then, in aggregate, comprise a Scrum of Scrums through which releases would be co-ordinated. The Product Owner and ScrumMaster would work across all development teams.
I'd try and keep the development teams focused on the technology area (1 for PHP, 1 for Java, 1 for Ruby). That would at least reduce the technical skill silos *within* each team. I'd think about having the QA, BA and UX experts assisting the PO so he or she can understand the product requirements and make credible decisions about it, including the acceptability of incremental releases.
This isn't ideal, because it means crafting a Definition of Done for each team that only takes an incremental release as far as deploying into a QA environment. There'd be a lot of work to do at a Scrum of Scrums level to manage the release train and to mitigate the risks around integration testing, and also to ensure that release feedback / lessons learned makes it to the relevant team for consideration.
I hope that the above is of at least some help to you. If not, I might refer you to the DSDM method which has a wider range of roles than Scrum, and supports larger team sizes. It's less operationally focused than Scrum but it could provide some initial process and role mappings. Whatever you decide, let me reassure you that your situation is by no means unusual, and that knowing how and when to compromise is half the battle in Agile transitioning.