HiveMind對Translator的支持由一個叫做TranslatorManager的類負責管理。考慮到對Translator的擴展性，它對Translator的組織比較特別。首先，它需要所有的Translator都繼承同一個接口，並且對構造函數也作了限定。其次，它通過擴展點配置來擴展自身。
在HiveMind的framework包中有一個名爲Translators的配置擴展點，在它的schema中定義了配置translator的格式。有趣的是在這個schema中遞歸的使用了Translator屬性，使整個格式讓人看上去很費解。解決這個循環調用的方法是在內核預設Translator的目的就是支持在生成擴展點的時候不會造成請求循環。當有請求向TranslatorManager申請Translator時，TranslatorManager並不會馬上去讀取配置擴展點的數據，只有當找不到需要的Translator時纔會去讀取Translator的配置數據。因爲預設了class，service，smart，instance這四個Translator所以在讀取配置數據時不會產生對Translator的循環依賴。
在預定的Translator有一種叫做object的Translator,它需要ObjectProvider配合使用。ObjectProvider的作用和Translator非常相似，完成的工作也很相像。不同的是ObjectProvider必須繼承另外的接口。這樣做的目的，一方面可能是爲了增加靈活性，讓Object可以有多種途徑取值，而不用爲每種取值方式從新編寫一個Translator，也不用知道當前有那些ObjectProvider可用。另一方面，這樣寫也可以讓取值的語意更加明確，因爲Translator屬性中必須使用一個前綴來申明用那一種ObjectProvider來獲取對象。比如說當應用中集成了spring之後，如果想獲取spring中的某一個bean,那麼使用如下的格式即可<... value = "spring:beanName"/>。
Translator是HiveMind內核支持的一項工作，並且可以通過配置來擴展自己。在其它HiveMind內核支持的工作都可以看到這種現象，內核代碼和關鍵的配置是不能完全脫離的。至少爲了更高一點的效率是不能完全脫離的。