Hi Mark, I can reproduce this. The month printed in the Blog.Archive page seems not to take the current locale into account. If one creates a test page with only the content: {{velocity}} #set($monthFormatter = $xwiki.jodatime.getDateTimeFormatterForPattern('MMMM')) #set($tempDate = $xwiki.jodatime.mutableDateTime) $monthFormatter.print($tempDate) {{/velocity}} and then viewing this page and appending "language=pt_BR" to the URL shows the month in English; however appending "language=pt" shows it in Portuguese. Extend the check: {{velocity}} #set($monthFormatter = $xwiki.jodatime.getDateTimeFormatterForPattern('MMMM')) #set($tempDate = $xwiki.jodatime.mutableDateTime) $monthFormatter.print($tempDate) Language: $xcontext.getContext().get('locale').getLanguage() / $xcontext.getContext().get('locale').getDisplayLanguage() Country: $xcontext.getContext().get('locale').getCountry() {{/velocity}} and one can see that for "language=pt" it correctly reports language as "pt / Portuguese" (and Country as empty) but for language=pt_BR one wrongly gets a language as "pt_br" (and no country). That is not looking good :( I can reproduce the issue with 6.4.7, so it is not a very recent thing. Interestingly only the "locale" object in the "context as map" is wrong, with the "$xcontext.getContext().getLocale()" everything works fine. So either the jodatime plugin uses a deprecated API with the context.get('locale') or the calculation in that context.get('locale') should be fixed. I guess I should know what is the case, but I have to admit I dont :( That is a tough one; the actual translations are in the ApplicationResources_pt_BR.properties which is a file packages in one of the *.jar- files in the WEB-INF/lib directory (I think it is xwiki-platform-legacy-oldcore-7.4.jar) The translation keys are either platform.livetable.paginationResults=Resultados or: platform.livetable.paginationResultsMany=Resultados <span class\="currentResultsNo">{0} - {1}</span> de <span class\="totalResultsNo">{2}</span> it is possible that you have installed any extension that overwrites these keys? (You can try to search for "platform.livetable.paginationResults*" in the normal wiki search; do not forget to set "Display hidden documents" to try in you user preferences page) hope this helps a little Clemens

I tried the search on "platform.livetable.paginationResults*" with xwiki installed both in tomcat8/webapps/xwiki and in tomcat8/xwiki/ROOT. In both cases, there was no result (or Nenhum resultado in Portuguese). On the installed extensions page, it shows the following that I've installed explicitly: Mocca Calendar Application Meeting Application Admin Tools Application XWiki Enterprise Flavor - Main Wiki All of the other ones listed were installed as dependencies. There are a couple of extensions that don't have pt_BR localization (such as Meeting and Full Calendar). For those cases, I downloaded the source files, added in the pt_BR resources file, rebuilt the extension and imported the resulting xar file. -- View this message in context: http://xwiki.475771.n2.nabble.com/Translation-problems-tp7597763p7597772.ht… Sent from the XWiki- Users mailing list archive at Nabble.com.

The workaround you suggested didn't have any effect. To analyse the problem a bit further (and verify that I was creating the translation page correctly), I inserted a spelling error in the Translations page. The spelling error was displayed as expected if I deployed the app to a path other than ROOT. But in ROOT that translation page is still not used. Maybe this one is a candidate for Ripley's Believe It or Not. I did all of the new translations via the http://l10n.xwiki.org/xwiki/bin/view/L10N/ <http://l10n.xwiki.org/xwiki/bin/view/L10N/> site (logging in there and making the edits on the forms). Then I downloaded the Application Resource file. Do I still need to do a github pull request or send you the files? I corrected one spelling error in the core resources before the 7.4 release and noticed that the correction was automatically included in 7.4. I guess the core is built using a different process than the extensions. Regards Mark -- View this message in context: http://xwiki.475771.n2.nabble.com/Translation-problems-tp7597763p7597793.ht… Sent from the XWiki- Users mailing list archive at Nabble.com.

What is the easiest/standar process for incorporating new translation resource files from the translation site before the next release of the core or an extension? So far I've been downloading the source for the extension, adding in or replacing the translation resource file downloaded from the translation site, rebuilding the extension and importing the xar file. For the core resources, I replaced the resources file in the jar. -- View this message in context: http://xwiki.475771.n2.nabble.com/Translation-problems-tp7597763p7597804.ht… Sent from the XWiki- Users mailing list archive at Nabble.com.

I have been updating the translations on the l10n site and then downloading the resource files. My challenge is that, sometimes, I don't want to wait for the next release. My perception is that, for extensions, the wait until the next release can be quite long (not a surprise). Speaking in complete ignorance of the implementation challenges, I think it would be ideal if the translations could be updated separately from the releases. -- View this message in context: http://xwiki.475771.n2.nabble.com/Translation-problems-tp7597763p7598380.ht… Sent from the XWiki- Users mailing list archive at Nabble.com.

I've started doing that. But I could not figure out how to set multi-line values in the translation wiki page - for example, the Sandbox test pages. For those ones, I exported the Sandbox page in a xar file, added in the new translation xml file, and then imported the new xar file. Thank you for your patience in explaining all of this. Mark Sack -- View this message in context: http://xwiki.475771.n2.nabble.com/Translation-problems-tp7597763p7598387.ht… Sent from the XWiki- Users mailing list archive at Nabble.com.