GWT i18n - Plural Forms doesn't work at all? - gwt

I'm using GWT internationalization Messages. The documentation for Plural Forms says this should work:
#DefaultMessage("{0} {1,number} hours {2}")
#PluralText({"one", "an hour"})
String hours(String prefix, #PluralCount int count, String suffix);
Well, it doesn't. Whatever value of count it still delivers DefaultMessage (e.g. "1 hours ago"). Same if I use a .properties file:
hours[one]=an hour
hours[few]=some hours
hours={0} {1,number} hours {2}
Is there a bug in the docs or in GWT (I'm using GWT 2.0.3) or in me? If any of the two former, anyone knows of a workaround?
EDIT: More clues to this mystery. I can get plural handling to work if I don't rely on default locale handling. That is, I need:
In my module's gwt.xml file:
<extend-property name="locale" values="en"/>
In my Messages extentsion:
#DefaultLocale("en")
public interface MyMessages extends Messages { ...
Explicitly load the "en" locale by appending to the URL
&locale=en
See http://groups.google.com/group/google-web-toolkit/browse_thread/thread/80ae300213cc6adb where I have cross posted this question.
EDIT 2: The reason I entered this GWT plurals land is that I'm creating a "GWT HUman Readable Relative Timestamps" module. Open sourced at GitHub: http://github.com/PEZ/GWT-Relative-Time Please check it out. It'll very soon have correct singular forms and support for some languages. =)

Also I think it will save people time to know that the default English plural rule only supports "other" and "one".
DefaultRule_en.java uses DefaultRule_1_0n.java
So you have to redefine DefaultRule_en.java if you want to use "none","two",few"...
You can see the available rules in the package com.google.gwt.i18n.client.impl.plurals.

Getting used to answering my own questions =) Here's cross post of my "answer" on the GWT Google group:
There seems to be a bug with the default locale handling. Here's how I have reached that conclusion:
I wanted to add some locales to my module. Figured I could get a boiler plate for the properties file if I used the #Generate annotation. I noticed that it created both an _en.properties file and a _default.properties. What's more; the _en file completely lacked the plural form info! The _default file had them though.
I then moved the _defaults file to the same directory as my TimeMessages.java file and renamed it TimeMessages_default.properties.
With this in place I can remove <extend-property name="locale" values="en"/> from my module's .gwt.xml file and, more important, the &locale=en from the URL when running my app. I still need the #DefaultLocale("en") annotation though, even though the documentation clearly states that this is not necessary.
In conclusion, if you run into this problem, try:
generating properties files using #Generate
place YourMessages_default.properties side by side with YourMessages.java
prepend the YourMessages interface with a #DefaultLocale("en") annotation.
About that #Generate. This is what worked for me. Just before my extension of the Message interface:
#Generate(format = {"com.google.gwt.i18n.rebind.format.PropertiesFormat"})
The GWT log said it created my properties file, but I couldn't find it. I fixed that by adding the compiler flag -extra extras and then found the properties files generated in the extras directory. Including this info here since I spent more than an hour figuring it out.

Another solution from the gwt issue list here:
You have to define the #DefaultLocale in the MyMessages.java:
#DefaultLocale("en")
public interface MyMessages extends Messages {
public String items(#PluralCount #Optional int count);
}
and in MyMessages.properties:
items={0} items
items[one]=one item

One more thing I found is that you can define a fallback locale like this:
<set-property-fallback name="locale" value="en"/> in your module XML file

Related

What is the correct way to specify DC metadata for a multi-language ePub?

I am developing an ePub. In the content.opf file I have to specify a series of metadata by using DC standard. For example dc:title and dc:creator.
However my book is a multilanguage book, that is, it contains two translations of the same text: English and Russian. The standard reference manual states that I can have more dc:language statements. For example:
<dc:language>en</dc:language>
<dc:language>ru</dc:language>
but it does not say how to specify the other metadata for more than one language. Consider, for example, dc:creator. I tried
<dc:creator xml:lang="en">Dario de Judicibus</dc:creator>
<dc:creator xml:lang="ru">Дарио де Юдицибус</dc:creator>
I get an error from the distribution platform validator, which states that the format of ePub is not correct. It looks like I cannot use xml:lang in dc:creator even if, in theory, that is an XML attribute that can be used with any XML tag. Same for dc:title:
<dc:title xml:lang="en">My Book Title</dc:title>
<dc:title xml:lang="ru">Название Mоей Kниги</dc:title>
Could someone who has had to face the same problem as me, namely writing the OPF for an ePub that contains a text in multiple languages, tell me what is the correct way to do it? In the standards for the OPF 3.x I have not been able to find any useful information to establish this.
SOLVED
I verified my code with one of the author of the W3C specifications for OPF and he told me that what I wrote is correct, but that some validator is not used to multi-language documents, so that the problem is the validator, not the code. I write this in case someone else may have the same problem.

GSettings, glib-compile-schemas and Eclipse

I am building this Gtkmm3 application in Ubuntu and wanted to explore GSettings. All was going well while following the instructions at the 'Using GSettings' page and then it was time to configure the make files. I use Eclipse 2019-12 IDE with CDT (V9.10) and 'GNU Make Builder' as the builder. I'm totally perplexed as to how to introduce the macros listed in the GNOME page into the make files. I even tried changing the project to a 'C/C++ Autotools Project' using Eclipse but still the necessary make files to add the macros were missing. Creating a new project with GNU Autotools does create the necessary make files but I was not able to get pkg-config to work with it.
Can anyone point me to some resource which explains how to compile the schema and how & where to load the resultant binary file (externally if necessary). I'll consider myself blessed if someone has already made a Gtkmm3 C++ application with GSettings support using Eclipse IDE in Linux and can share the details.
Finally I figured. Thought I'll share my findings here. Actually some one out there had explained this for python (link below).
Using GSettings with Python/PyGObject
Creating the schema
For the developer the work starts with defining a schema for the settings. A schema is an XML file that looks something like this.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE schemalist SYSTEM "gio_gschema.dtd" >
<schemalist>
<schema id="org.gtk.skanray.emlibrary"
path="/org/skanray/emlibrary/" gettext-domain="emlibrary">
<key name="wave-pressure-ptrach-visible" type="b">
<default>true</default>
<summary>Set visibility of 'Ptrach' trace in pressure waveform.</summary>
<description>The pressure waveform shows multiple traces where 'PAW' is always enabled and additionally 'Ptrach' can be displayed. This settings affects the visibility of the trachial pressure trace shown in this waveform channel.</description></key>
</schema>
</schemalist>
The file name has to have a ‘.gschema.xml’ suffix. The schema file should be in the project path, only so that it gets pushed to SVN.
Best would be to use an XML editor (e.g. Eclipse) that supports design of XML files from a DTD file. Use following DTD file.
gschema.dtd
It is possible to store anything derived from GVariant into GSettings. Refer to following page to understand the basic types and the ‘type’ attribute to be used in the schema.
GVariant Format Strings
Compiling the schema
With the schema ready, (sudo) copy it into /usr/share/glib-2.0/schemas/ then run,
> sudo glib-compile-schemas /usr/share/glib-2.0/schemas/
At this point, the newly added settings can be seen / modified using dconf editor.
Accessing GSettings from the application
Coming to the main event of the show, this is how an application can read ( and / or write) settings. It is not necessary that one needs to bind property of an object to a ‘key’ in GSettings, it may be queried and used as well. Refer to GSettings API reference for details.
Glib::RefPtr <Gio::Settings> refSettings = Gio::Settings::create(“org.gtk.skanray.emlibrary”);
CLineTrace * pTrace = NULL; // CLineTrace is derived from Gtk::Widget
…
pTrace = …
…
if(refSettings)
{
refSettings->bind("wave-pressure-ptrach-visible",
pTrace,
"visible",
Gio::SETTINGS_BIND_DEFAULT);
}
Now you can fire up dconf editor and test the settings.
NOTE
Bindings are usually preferred to be made in class constructors. However binding to ‘visible’ property of a widget could be a bit tricky. Typically the top level window does a show_all() as the last line in its constructor. However constructors of the children of top level window would have completed executing including making the bindings. If there were settings that had stored ‘visibility’ as false then the top level window’s call to show_all() would mess up with that setting. In such cases it is advised to perform the bind one time in the on_map() handler of the respective class.

Play framework localisation is not working in production

If I run my play framework application with "play run" the localisation is fine. But if I do a "play dist" then use the start command, then the original English messages appear.
I have found, that if I change the classpath order in the start script putting the jar containing my messages file to the first place, then the localisation is fine.
Is there any better way to do this?
It is the same, if I copy the conf/messages to conf/messages.hu and set application.langs="hu" in the application.conf.
And stays the same, if I change my browser settings, so this is in the request header: "Accept-Language:hu,en-US;q=0.8,en;q=0.6". Still English messages (only, if they are the built in keys. My custom keys are translated correctly).
We have figured it out.
There is a custom field constructor used. My assumption was, that it is using the implicit lang parameter, but this is not the case. The lang must be given to the elements.errors() as parameter, and the current lang setting is stored in the elements.lang attribute. This is stated in the documentation, but we missed it. So the implicit lang parameter should not be used in the field template, because it contains wrong value.
The solution was this: #elements.errors(elements.lang)
#elements.input
<span class="errors">#elements.errors(elements.lang).mkString(", ")</span>

How to solve validation error on xsi:noNamespaceSchemaLocation in jdoconfig.xml

Since I updated today to GAE 1.7.2.1, I'm having validation errors in eclipse in all my jdoconfig.xml files.
I have the default jdoconfig.xml content :
[...]
<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig">
[...]
And eclipse validation throws:
Referenced file contains errors (http://java.sun.com/xml/ns/jdo/jdoconfig).
For more information, right click on the message in the Problems View and
select "Show Details..."
When clicking on details I can see a bunch of lines like:
s4s-elt-character: Non-whitespace characters are not allowed in schema elements
other than 'xs:appinfo' and 'xs:documentation'. Saw 'var_U = "undefined";'.
In different lines and different content in "Saw ... "
It occurs in every single project I start using the "New Web Application Project..." from the google plugin.
So does anyone have this problem? Any fix?
Try this:
<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd">
Per the answer here Validating jdoconfig with incorrect url
The xmlns is not a real file/directory, more a namespace, so ought not exist! The version is appended to get the real XSD file, namely http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd
There are a couple problems here.
The syntactic problem is that the URI you are giving as the value of xsi:noNamespaceSchemaLocation is redirected to http://www.oracle.com/technetwork/java/index.html and returns an HTML document. The XSD validator you are using is trying without success to parse
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8" />
<script type="text/javascript">
var _U = "undefined";
var g_HttpRelativeWebRoot = "/ocom/";
var SSContributor = false;
...
as an XSD schema document, and for one reason or another its attempts to explain what went wrong focus on finding the string var_U = "undefined" in a place where it was not expecting to see character data.
Then there are some conceptual problems.
Your document is in a namespace named http://java.sun.com/xml/ns/jdo/jdoconfig. Why on earth are you pointing the schema validator to a schema without a target namespace (which is that noNamespaceSchemaLocation does), if you want to validate your document? Given that (at least some of) your document's elements are namespace-qualified, you will want (as joncalhoun has already suggested) to use xsi:schemaLocation and provide a pair telling the validator where it can find a schema document for each namespace you want it to know about.
It's possible that a schema document used to be served from the location http://java.sun.com/xml/ns/jdo/jdoconfig, but since it's apparently the standard namespace named for your vocabulary, that's not actually very likely. Most systems distinguish fairly reliably between namespaces, which are abstract and poorly defined things, and schema documents, which are typically XML documents that define specific XSD schema components for a given namespace. It's not illegal to use the URI for a schema document as the name of a namespace, but it is unusual.
Note that the URL given by joncalhoun for the schema document (http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd) actually does resolve (after redirection to http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/jdo/jdoconfig_3_0.xsd) to a schema document, which specifies http://java.sun.com/xml/ns/jdo/jdoconfig as its target namespace. (This means that even if you did succeed in retrieving this schema document by giving its URI as the value of xsi:noNamespaceSchemaLocation, you'd then get an error because it's not a schema document for elements and attributes with no namespace.)
This makes me think that you should read joncalhoun's answer again and try it again, carefully. If it didn't work when you tried it, my money says that either you tried something similar but not exactly what he suggested, or it solved this problem but that simply exposed some other problem, which is easy to mistake for failure.
One solution is setting XML Catalog in Eclipse preferences.
Details:
Entry element: URI
Location: http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd
URI: http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd
Key type: Namespace name
Key: http://java.sun.com/xml/ns/jdo/jdoconfig
The syntactic and conceptual issues C.M. mentions are a problem with the plugin and Google's settings where both recommend,
xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig
I don't specifically use jdo but I still get the validation error with this namespace. It was fine with this namespace until just recently.
I used LuboM's method and it worked for me. Neither LuboM's nor joncalhoun's is the answer though since it ties me in to jdo 3.0
Oracle is going to have to provide the fix. Apparently their intent was to resolve the namespace issues themselves across versions of jdo.
This is what I did to fix it:
<?xml version="1.0" encoding="utf-8"?>
<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd">
I am success on this:
Right Click Project -> Properties -> Validation -> XML Syntax
Enable Project Specific Settings (If you need)
Under Validating Files, For No grammar Specified Select "Warning"
Click "Ok"
If you ask for Validating the file, Click "Yes"
You can do the same for all the projects by going to Windows -> Preferences.
Make sure you are validating the file (Step 4).
I had the same issue, and excluded just this jdoconfig.xml file from Eclipse's validation. Even though your Eclipse throws an error for it, it in no way affects being able to deploy the project to GAE correctly.
Here is how to exclude just the jdoconfig.xml file to get rid of that pesky error:
Right click on your Eclipse Project, ->Properties->Validation->XML Validator, click on the "..." button for further options.
You should see Include Group and Exclude Group options. Click Exclude Group->Add Rule...->Folder or file name, and browse to your file.
Clean or rebuild your project. The validation error should be gone.
This worked for me in Eclipse Luna.
You might have try this path to solve your problem:
<?xml version="1.0" encoding="utf-8"?>
<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig">

Query with toLocalizedTime in Plone

I'm using toLocalizedTime to output a date, as below
<span tal:content="python:here.toLocalisedTime(date.get('start_date'))"/>
This outputs eg. 2007/08/02, I'm just curious as to how one would alter the output so that it reads 02/08/2007
I'm not having much luck finding much info on toLocalizedTime, would someone point me in the right direction?
This depends on whether you have English selected as the site language (Site Setup >> Language). If so, then the default settings are used. You can change the defaults by dropping down into the ZMI, then into 'portal_properties', then 'site_properties'. The fields to change are either 'localTimeFormat' or 'localLongTimeFormat' depending on whether you pass in 'long_format=1' to the toLocalisedTime function.
If on the other hand, you have translations set up, the format may instead be pulled from the translation file for the locale selected. I'm not sure what is the easy way to change the format in this case (other than switching the site back to English). I guess you can register your own translation file but I've never needed to do that so you're going to have to look up the details.
Date string formatting follows the Python rules (http://docs.python.org/library/time.html#time.strftime).
Perhaps even more detail than you need:
here.toLocalizedTime()
is defined in the plone browser view at...
CMFPlone/browser/ploneview.py
which looks up the 'translation_service' utility, to call its 'ulocalized_time' function, defined at...
CMFPlone/TranslationServiceTool.py
which itself calls the 'ulocalized_time' function defined at...
CMFPlone/i18nl10n.py
As always, you can learn interesting things by grepping the source code ;-)
For an up to date answer for Plone 4.3 (after going through the source code)
These fields are now in the registry found at:
http://localhost:8080/yoursite/portal_registry
Then filter on "i18nl10n", which should give you the 4 fields you need to change.