Hi5 has a large audience in Spanish-speaking markets, Thailand, Romania, Portugal, and many other countries. How much more popular would your application be if it supported Spanish, Thai, Romanian, Portuguese and 50 other languages?

To simplify the translation process for applications, hi5 has connected its OpenSocial development platform to its community-based translation system. For the past six months hi5 has been building teams and language tools to translate the hi5 website into 25+ new languages; now, that same community and toolset is available to OpenSocial developers to translate the applications.

Translations are performed only by users of the application who are members of the hi5 translation team for that language. In addition, developers have complete control over all translations translated text within the system, and may delegate this editorial responsibility to specific translators or reviewers.

Translators have access to the hi5 language tools on the application canvas page. Translations take place in context, directly adjacent to the functioning application.

Developers can preview the translations, perform any required edits, and then publish, making the translation available to all hi5 members. Furthermore, as a developer, you can download the translated text for deployment in any OpenSocial compliant container.

Getting Started

The translation process begins by internationalizing (i18n) the application. The OpenSocial specification is i18n-ready and hi5 provides Internationalization guidelines to help you with this step.

Once the application is internationalized, developers will Reload the application and select to Receive hi5 translations. Developers need to set the application's Default Locale to indicate the language used in the default message bundle. This loads the application's text into the translation system and makes it available to the translators who use the application.

Although the translation teams are most accustomed to translating from English to other languages, as is the case on the hi5 website, the translation tool for applications supports translation from any source language as defined in the hi5 system. This permits maximum flexibility in development and translation.

A new tab has been added to the Development Console, showing the translators' progress. As translations become approved by the community, those languages will appear atop the list with messages indicating New Translations available for download. Exporting the translated message bundle, updating the app xml and reloading the app publishes the new translations.

Additional Resources

For more information on the translation system and processes now available to you, please refer to the following documents:

• Developer Guidelines for Translating hi5 Applications - provides an overview of the translation program for OpenSocial applications.
• Linguist Guidelines for hi5 Applications - explains the role of the hi5 Linguist in hi5's Volunteer Translation program.
• Linguist Instructions for Translating hi5 Applications - provides how-to instructions for Linguists assigned to a hi5 application.
• hi5's Internationalization Guidelines - the internationalization section of the hi5 Developer wiki.
• OpenSocial Specificiations - Google's OpenSocial home page.

<os:message key=”resource” />

<os:message key=”received_gift” gift=”pizza” friend=”Joe”>You received a ${gift} from ${friend}</os:message>

1. ${} for variable substitution
2. <for-each> for iteration
3. <if>/<else> for conditional logic, and
4. <os:message> for gadget resource localization.

Developers will have to authenticate themselves by creating an authToken — any of the developer accounts associated with an application can be used to access the stats for an application. Statistics can be generated for all or some of the applications owned by the developer account requesting the data.

The API has three endpoints:

1. metrics/daily: These are daily stats, not uniq'ed per user. You can query the data for a range of dates, not exceeding 30 days. Requests for more than 30 days will be truncated to 30 days, starting at the start date.
2. metrics/dailyuniques: These are the same type of stats as returned by metrics/daily, but accounting for uniques. This means that if a single user views a canvas page on your application more than once, it will count as just 1 unique canvas page view in these metrics.
3. metrics/total: These are total stats calculated for the applications, aggregated since your application launched.

The input parameters are supplied in the URL and the parameters and the acceptable values are all case sensitive. Only the Hi5AuthToken parameter is required

Parameters

1. metric: If this parameter is not specified, then all available metrics are displayed. You can request the following metrics with this parameter:
   1. install: Total number of installs
   2. remove: Total number of removes. You will have to subtract this from the total number of installs to get the net installs of your application for the applicable time period.
   3. view_profile: Calls to the profile module
   4. preview: Calls to the preview module
   5. canvas: Calls to the canvas module
   6. block: Block requests generated in response to emails and notifications generated by your application_,_ and on the My Applications page.
   7. api_request: API requests sent to our API servers by your application
   8. report_abuse: Notifications generated by your application marked as spam
   9. activity_requested: Requests to generate a Friend Update
   10. activity_sent: Friend Update requests fulfilled
   11. invite_requested: Friend Invite requests generated. Note that this counts a request containing multiple friends as one request
   12. invite_sent: Friend Invite requests fulfilled
   13. notification_requested: Notification API requests made to the API servers
   14. notification_sent: Notification API requests fulfilled. Note that when an API request is fulfilled, not all the recipients in the API request might receive the request, as some might already have received the limit of per-recipient notifications allowed.
   15. all: All of the above
2. context: The context breaks up each statistic in the metric parameter based on the origin of the corresponding action. Note that not all contexts are valid for all actions — for example, blocks can only occur in the invite, myapps and notification contexts, by definition. If context is not specified then breakdown by context will not be displayed. The possible values of context are:
   1. activity_stream: From all links in a Friend Update, if that link is on a user's home page, or from a Friend Update's "More" link if the Friend Update is being viewed on the logged-in user's or someone else's profile.
   2. apphome_friend: From the My Applications page of the currently logged-in user, when the user clicks on a recommended application (currently, applications installed by a user's friends)
   3. apphome_owner: From the My Applications page of the currently logged-in user, when the user clicks on one of their own applications (currently, user's recent applications)
   4. gallery: From the hi5 Application Gallery
   5. homepage: From the homepage applications box at the top right of the page
   6. invite: From a friend invite
   7. myapps: From the Manage Applications page
   8. notification: From a notification
   9. other_profile: From the profile of someone other than the currently logged-in user
   10. own_profile: From the profile of the currently logged-in user
   11. profilenav: From the View More link on the Profile module, and from the Applications drop down in the navigation bar at the top of the Profile page
   12. unknown: From an unknown context, usually generated when the user comes from a link placed in a Profile module or Friend Update by the application (Note that this number is inflated because invites are not being tracked correctly; this will be fixed soon.)
   13. all: All the contexts applicable to a given action
3. start and end: The start and end dates, respectively, in YYYY-MM-DD format. The dates must be "consistent," that is, the end date cannot precede the start date, and they must both be valid calendar dates. A range greater than 30 days generates an error. If no dates are specified then data for the latest available timestamp (typically, for "yesterday") is displayed.
4. Hi5AuthToken: The auth token generated via the REST API for your API key and login information.
5. api_key: The acceptable values are the API keys of the applications owned by the developer making the request; API keys for other applications will generate an error and return no statistics. To return statistics for more than one application (but not all applications) owned by you, specify the api_key parameter multiple times. If no api_key is specified then the one that was used to generate the auth token will be used.

To begin, we will not rate limit this API and expect that the volume will be no higher than once a day per application. Improper use of this API will lead to the offending API keys being blocked from access to this functionality.

We look forward to your feedback. Thanks!

• Tuesdays, 9am - 11am
• Thursdays, 1pm - 3pm

To manage this ecosystem in as efficient a manner as possible, we are introducing a new automated system that will implement notification quotas. To date, we have been moving these switches manually but the communication overhead has been too high. The automated quotas will respond daily to abuse report rates and usage. Specifically, the fewer times our members mark a notification as spam and the more they click through to engage with the application, the more notifications your applications will be able to send.

We think our automated system will help the platform respond in the most timely manner to positive user perceptions of applications and notifications. Very soon, developers will be informed via the response to (rejected) API requests for sending notifications if they are in violation of quotas. We also expect soon to expose the actual quotas on a daily basis via the Developer Console.

If you have any questions about the quota system or suggestions on how else we can support your apps on hi5 while also best serving our membership, please get in touch with us via email, our discussion forums or the wiki --- all contact addresses are available on http://developer.hi5.com.

• A standard REST API based on OpenSocial 0.8
• Better OpenSocial JavaScript features including pubsub.
• OAuth support.
• OpenID Provider support.
• More supported profile fields.
  

• Use the new OpenSocial REST service at http://sandbox.hi5.com/social/rest/
• Use a test application with our new OpenSocial Gadget Server

You will need an OpenID login to authenticate yourself. Click on OpenID Login at the top right. On the login page, you have to choose an "OpenID provider" from the drop down --- you will see a list of familiar sites that provide login services. The provider you select will typically lead you through a series of simple steps to log in to our wiki. Please contact us at platform-help@hi5.com if you are having trouble using OpenID.

Please submit your bug requests to the tracker (View Tickets in the left navigation bar) -- this will help our team take application developer needs into account when prioritizing changes to the platform. The discussion forum allows you to add topics in different categories. We would love to hear from you if you would like to add new categories to the forum.

The main page and some of the tutorial material on the wiki will be protected to ensure that spammers don't get in the way of new developers who are trying to get their applications off the ground quickly. A rudimentary set of navigation links has been added to the bottom of the main page for you to start editing.

May a million beneficial conversations begin!

We believe we are now in better shape to handle the high load conditions we saw previously (and expect will continue with the ongoing success of our platform). An important learning for us was to maintain multiple communication channels with developers to provide up-to-the-minute updates and other valuable hi5 information, whether through our IRC channel, discussion forum or this blog. More recently, we've also added a Twitter account to our portfolio of communication tools, and a couple rounds of temporary down times have already been twittered (tweeted?) over the last couple of days.

Next week, we'll add yet another way of communicating with us and with each other. Specifically, we will be opening up the wiki on our Developer Center website to enable collaboration. If you have any suggestions for the structure of and navigation between the developer-accessible pages (such as posting sample code, creating feature request pages, interacting with our users to know what apps to build, etc.), please do let us know.

Beyond communication with the developer community, another focus for us has been on setting fair standards for application notifications. Our users expect applications on hi5 to behave according to the high standards we've set for other features of our service, which among other things means that installing applications will not overwhelm their in boxes with irrelevant or misleading information. We've applied over four years of learning into the guidelines we set for creating effective and useful viral channels for our service, and are continually evolving our developer guidelines to inculcate these learnings, while also reacting to the fluid nature of the application landscape. Please check out the latest updates to our guidelines, if you haven't already. We welcome your feedback.