I put all my translation tables into the etl schema and kept the facts and dimensions in dbo.
Consider using a more elaborate schema for the facts and dimensions. One suggestion above was by functional area. I identify via schema the source database for the tables. As I use views for all the dim and fact tables (a suggestion from Kimball's 3rd edition book) the schema for those identifies the supported cube. Works great, although sometimes the DSV is a little fiddly when working with views versus tables.
Thanks, Ron. Along that line, I was thinking of putting aggregate tables or a presentation layer into another schema. My tables have multiple sources, such as all customers into one customer dimension.
I have some tables with multiple, but there's usually a primary source that provides most of the data. You might consider "common" or some such. Just suggesting minimizing the use of the dbo schema.