Hi, The subject of this mail says it all but I will detail. I'm trying to follow some standard rules, whenever possible, in my contrib project. So, concerning translation properties recommendations [1], for the pretty name of a field (named "from") of a class (named "MailClass", from space "MailArchiveCode"), from module org.xwik.contrib:xwiki-contrib-mailarchive-ui, I would maybe use: contrib.mailarchive-ui.MailArchiveCodeMailClassFromPrettyName or contrib.mailarchive-ui.MailArchiveCodeMailClassFrom or anything else for the last part really... I could consider that a good candidate for the "top level project" could be "contrib" in my case. I could also consider it to be "mailarchive" by the way, as I'm clearly out of scope of that xwiki development practice. But then if I follow [2], I find a completely different recommendation, and it's even automated if I apply it (for pretty name). I would then use: MailArchiveCode.MailClass_from Then if I want to define another translation key for the "hint" of this field, I could decide to append "Hint" or "_hint" or ".hint" to the property I defined for the pretty name (ie the label in the form ?). Or maybe there's some more automated way as for the pretty name, but I didn't find it described in on x.org... As I'm a curious guy I also checked [3], I know it's not a validated document, but as anyway that use-case is already a bit out of scope ... But it seems not to solve the problem, and I'm not sure to understand why there's such distinction between a "class field label" (that should use Space.Class_field) and a form label for a field of that class (that would use <prefix>.label), as it really seems the same to me. Or it could be different, but I think main use-case is to create an XClass, and create a Sheet for it, and display a form for all fields from that class, point. In rare cases, you might want to display another form on that same class in another location (page/sheet), but it's unfrequent and it should be even more unfrequent to use different labels in that case ... And usually your end-users won't have to update the XClasses coming from your application, so you don't really care about internationalizing the XClass in itself - you care more about internationalizing the forms derived from that XClass. Mixing all that together and shaking it a little, personnally, this is what I would follow, for internationalizing a sheet displaying MailArchiveCode.MailClass objects: MailArchiveCode.MailClass_from=... mailarchive.mails.x.from.label=$msg.get('MailArchiveCode.MailClass_from') mailarchive.mails.x.from.hint=... mailarchive.mails.x.from.help=... ... ## For livetable mailarchive.mails.tableColumnHeaders.from=... ... Here I used "mails" as the interesting (defining) part of the XClass ("mail") with an 's' (as you usually don't create a unique object from an XClass...). I believe there should be something for 'x' level but I don't know what exactly ("form", "class", "xclass", "fields" ?). This also has the advantage of not following any defined rule :P Maybe I misunderstand things, and maybe (certainly) this is all too much far-fetched, but I like to follow standard ways as much as possible ... :-) If there's nothing more defined (or to be defined) for a contrib project, or any provided ui extension, then I'll do whatever comes to my mind and sorry for disturb ;-) BR, Jeremie [1] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTranslat... [2] http://platform.xwiki.org/xwiki/bin/view/DevGuide/TranslationsTutorial [3] http://dev.xwiki.org/xwiki/bin/view/Drafts/L10N+Conventions