Posts in Category "Technology"

Invoking ICU from Adobe AIR Applications

This article was originally written in English. Text in other languages was provided by machine translation.

Adobe Flash and AIR are ubiquitous platforms to develop rich internet applications. Flash is used for browser based applications and AIR is used for developing native platform applications. Both platforms have considerable support for globalization. Globalization enablement features like locale aware formatting/parsing, collation, case transforms, localization and multi-lingual text rendering are supported by both these platforms. But some more globalization features like text normalization, transliteration, Unicode character properties, encoding conversions, charset detections, Unicode string utilities etc are still missing in the Adobe AIR and Flash platforms. One of the primary reasons for not adding all these features inside the Adobe runtime platforms is the size of the software.

To overcome the size limitation issue, Adobe AIR and Flash can invoke the services of external dynamic libraries through ActionScript. There are some well known external libraries which have rich globalization support like ICU, GNU glib, Verisign IDN library to name a few. Fortunately the upcoming Adobe AIR 3.0 (now available as Adobe pre-release) has a wonderful feature called ActionScript native extensions, which is about ActionScript programming interface for a native code library like MS Windows DLL, Os X FrameWork, Android JAR or shared library or iOS static library. Please see Adobe AIR3 beta site on how to download and take part in the Adobe AIR pre-release. Please make a note that this native extensions feature is available _only_ in Adobe AIR platform, not in the Flash platform.

In this blog, I demonstrate a sample (Download air_icu ) application to invoke ICU from an Adobe AIR application on Windows platform. Readers are reminded that this is only illustration sample software and by no means production quality software. Hence readers must exhibit discretion in using this software as it is. The sample illustrates ICU word breaking, sentence breaking, utf-conversion and Unicode character property verification.

You will need the following software to build an ICU extension for AIR platform.

1         Building ICU extension for Adobe AIR

Adobe AIR t native extensions, also known as ‘ane’ or ‘ANE’ files are archived packages. These consist of

  • ActionScript wrapper classes calling into external DLLs
  • The external DLLs
  • XML file describing details of external DLLs

The archived ANE files are used just like SWC libraries in integrating into an AIR application. In other words, ANE file is a library and it has public ActionScript APIs.

Covering all details about the ActionScript extension is too much for this blog article, but I will explain the steps to build this sample and run. Below are the sequential steps and commands.

1.1       Building Windows AIR ICU Extension DLL

1)      The AirIcuExtensionWin folder has the Visual studio solution ‘AirIcuExtension.sln’. Open this in MS VS2010.

2)      The file AIRIcuExtension.cpp has the necessary code needed to interface with Adobe AIR 3 beta 2. It also has the wrapper routines calling ICU C functions.

3)      This is a DLL project and the build output is AirIcuExtension.dll

1.2       Building ActionScript Library

1)      Build the actionscript library using the below command.

C:Flex4.5.1bincompc.exe -source-path src -include-classes com.adobe.extensions.AirIcuExtension  -external-library-path C:air3_beta2frameworkslibsairairglobal.swc -output binAirIcuExtension.swc

The file in the folder srccomadobeextensions has the public class AirIcuExtension which calls the ICU routines. In this sample, calling ICU sentence breaker, word breaker, normalizer, utf-conversion and Unicode character property have been illustrated.

1.3       Packaging ActionScript native extension

Open the binAirIcuExtension.swc is a zipped archive. Open it using WinRAR or WinZip program and extract the library.swf file in the swc package into the AirIcuExtension/bin folder.

The folder srcresources contains file extension.xml, AirIcuExtension.dll and ICU dlls icudt48.dll, icuuc48.dll, icuio48.dll and icuin48.dll. The file external.xml defines the external library details to AIR runtime.

For simplicity, place the AirIcuExtension.dll, ICU dlls and extension.xml files in AirIcuExtensionbin folder. All these files are packaged into a zipped archive called AiricuExtension.ane using the following command.

C:air3_beta2binadt -package -storetype pkcs12 -storepass <passwd> –keystore <AIR certificate> -tsa none -target ane AirIcuExtension.ane extension.xml -swc AirIcuExtension.swc -platform Windows-x86 library.swf AirIcuExtension.dll icudt48.dll icuin48.dll icuio48.dll icuuc48.dll

Using Adobe FlashBuilder4.x or  C:air3_beta2binadt program, one can make an AIR certificate.

The output is an archive file AirIcuExtension.ane in the AirIcuExtension/bin folder.

1.4       Building the Test program AirIcuExtensionTest.mxml

Now that we built and packaged the native extension package AiricuExtension.ane, we are readu to use this and call ICU services in a test program.

The folder AirIcuExtensionTestsrc contains the test file AirIcuExtensionTest.mxml. The descriptor file AirIcuExtensionTest-app.xml has  the details of native extension. Using the mxml compiler, AirIcuExtensionTest.swf is built as follows in AirIcuExtensionTest folder.

C:Flex4.5.1bincompc.exemxmlc +configname=air -external-library-path ..AirIcuExtensionbinAirIcuExtension.ane -output bin-debugAirIcuExtensionTest.swf — srcAirIcuExtensionTest.mxml

The output swf file AirIcuExtensionTest.swf is placed in the bin-debug folder.

1.5       Building AIR package for executing AirIcuExtensionTest

The final step is to package the above AirIcuExtensionTest .swf and AirIcuExtension.ane files into an AIR executable folder.  Execute the following command

C:air3_beta2binadt -package -XnoAneValidate -storetype pkcs12 -storepass <passwd> –keystore <AIR certificate> -tsa none -target bundle AirIcuExtensionTest.air AirIcuExtensionTest-app.xml AirIcuExtensionTest.swf -extdir ….AirIcuExtensionbin

The output of the above command is a folder AirIcuExtensionTest.air. Inside the folder, there is AirIcuExtensionTest.exe. You can execute and see the output.

2         Conclusion

The sample illustrated how to invoke ICU from ActionScript. The AIR ICU extension is easy to build using the publicly available Adobe Flex SDK and AIR3 Beta 2 SDKs. It will be much easier to do all this in the future Adobe Flash Builder IDE using GUI. The advantages of this feature are

  • AIR developers looking to develop international applications for desktop or mobile have the full power of ICU at hand. Many Unicode features, encoding conversions, IDN conversion utilities, string processing, transforms and many more international features can be easily coded.
  • The native ICU extension once built can be used any any developer as it is a library.
  • The Actionscript APIs calling ICU can be coded using the same signatures as ICU C++ API. This eliminates the learning curve.
  • Since ICU is in native code, performance is not compromised.
  • Since it is ICU, developers can expect cross-platform behavior in AIR programs.
  • Since the extension is a AIR library, ICU updates can be easily re-packaged in to the ane file.

In the future once AIR3 is released, a full fledged ICU native extension with proper API definitions will be a great globalization project.

A lightweight auto-complete ActionScript example with a trie

This article was originally written in English. Text in other languages was provided by machine translation.

Auto-complete functionality is used widely over the internet and mobile apps. A lot of websites and apps try to complete your input as soon as you start typing.  In this post, I would like to introduce a simple ActionScript auto-complete solution by using trie data structure.

A trie is an ordered tree data structure that is used to store an associative array. All the descendants of a node have a common prefix of the string associated with that node, and the root is associated with the empty string. Starting from the root node, you can check if a word exists in the trie easily by following pointers corresponding to the letters in the target word. Trie is a well-known data structure in computer science; you can find the detailed information about trie through Wikipedia.

Here is a simple trie implementation in ActionScript:

* An simple data structure to store and look up words.
* @see for additional details.

public class Trie {
private var _rootKeys:Array;
public function Trie():void {

* Return a list of words which have the given prefix.

public function get(prefix:String):Array {
var results:Array=[];
var letter:String=prefix.substr(0,1);
var root:TrieNode=_rootKeys[letter];
if (root) {
getWordList(prefix, 1, root, results);
return results;

* Add a word to the object which can be matched as a prefix.

public function add(word:String):void {
var letter:String=word.substr(0,1);
var root:TrieNode=_rootKeys[letter];

if (!root) {
insertWord(word, 1, root);

private function traverse(root:TrieNode, results:Array, prefix:String):void {
if(root.children) {
for each( var c:TrieNode in root.children ) {
var node:TrieNode = c as TrieNode;
if( node.word ) {
results.push( prefix + node.value);
traverse(node, results, prefix+node.value );

private function getWordList(prefix:String,
results:Array):void {
var letter:String=prefix.substr(position,1);
var child:TrieNode=root.children[letter];
if (!letter || !child) {

if ( position<(prefix.length-1) ) {
getWordList(prefix, ++position, child, results);
}else {
if (!child.word) {
traverse( child, results, prefix);


private function insertWord(word:String,
root:TrieNode):void {
var letter:String=word.substr(position,1);
if (position==word.length || !letter) {

var child:TrieNode=root.children[letter];
if (! child) {

if (position==word.length-1) {
} else {
insertWord(word, ++position, child);

private function createNode(letter:String):TrieNode {
return new TrieNode(letter,false);

Format date and time in non-Gregorian calendars

This article was originally written in English. Text in other languages was provided by machine translation.

Although the Gregorian calendar is the most used civil calendar, there are other calendars used in different countries and regions.

Islamic calendar is used in many Islamic countries and it has quite a few variances. Japan uses the imperial calendar which identify the year with an era name(年号, nengō) and a number. Thailand uses a calendar that counts in the Buddhist era.

With flash.globalization package, you can easier format a date in non-Gregorian calendars. See the code below.

Difference between Flex SDK’s Matching Collator and Sorting Collator

This article was originally written in English. Text in other languages was provided by machine translation.

Flex SDK has two kinds of collators. Do you know the differences?

First of all, let me explain what a Collator is. The Flex SDK Collators are classes that are designed to compare two strings. Their compare functions return a numeric value to tell which of the two items is smaller or larger.

Here is an example:

    <s:SortingCollator id="c1"/>
        <s:TextInput id="uiInput1" text="ABC"/>
        <s:TextInput id="uiInput2" text="ABC"/>
        <mx:Text id="uiOutput" text="{, uiInput2.text)}"/>

This example shows 0 as the compare result by default. As you alter the inputs, the result becomes -1 if the first input is smaller or 1 if larger. See the screenshots below.




The difference in sorting

Now, let’s talk about the differences of Matching and Sorting Collators. Actually, they are essentially same but they have given some specific initial collation parameters good for general string matching (MatchingCollator) or parameters good for general string sorting (SortingCollator). Example below illustrates why two different collators are useful.

Assume you have following items in your Array. You want to sort the items and find a specific string from the items.

  • naïve
  • Naïve
  • naive
  • Naive
  • adolescent
  • youthful

If you sort items using a SortingCollator class with “en_US” (English spoken in U.S.) locale, you get following sort result.

  • adolescent
  • naive
  • Naive
  • naïve
  • Naïve
  • youthful

This ordering makes sense for most usages. (At least that is what we have hoped.) Lowercase letters come first over upper cases; letters without accent come first over ones with accent.

On the other hand, if you sort the items using a MatchingCollator, you get following result. (Result may vary as some attributes are ignored.)

  • adolescent
  • Naïve
  • naive
  • naïve
  • Naive
  • youthful

You may notice that upper/lowercase ordering and accent character ordering are not consistent with a MatchingCollator class. In fact, the MachingCollator class is not designed for sorting.

The difference in matching

Now, assume you want to search a specific string, “naive“, from the list. With a SortingCollator class, you get following result:

  • naive

Yes, only one string with a SortingCollator class.

On the other hand, with a MatchingCollator class, you get following result.

  • Naïve
  • naive
  • naïve
  • Naive

As you can see, the string comparison was done in more lenient manner with MatchingCollator class. Often such leniency is desired when searching strings.

Although SortingCollator and MatchingCollator behave differently as you have seen above, those classes are pretty much same underneath. In fact, they can mute to the other sibling by setting their properties. If you need to control more details of sorting/matching behavior, you also manipulate the properties. Please see the Flex SDK references for more details.


The example program used in this article

<?xml version="1.0" encoding="utf-8"?>
   <s:Application xmlns:fx=""
      <s:SortingCollator id="sortingCollator" locale="en_US"/>
      <s:MatchingCollator id="matchingCollator" locale="en_US"/>
      <s:Sort id="sort"/>
      <s:ArrayCollection id="arrayCollection" sort="{sort}" source="{wordList}"/>
         private static const wordList:Array = [
            "naïve", "Naïve", "NAÏVE",
            "naive", "Naive", "NAIVE",
            "adolescent", "youthful" ];
         private function setCollator(useSortingCollator:Boolean):void
            const collator:Object = useSortingCollator ?
            sortingCollator : matchingCollator;
            sort.compareFunction = function (a:Object, b:Object, fields:Array):int
               { return as String, b as String); }
            uiResult.text = "Sort Result:n" + arrayCollection.toString();
            uiResult.text += "nnStinrgs equal to 'naive' are:n";
            for (var i:uint = 0; i < arrayCollection.length; i++)
               if (![i], "naive"))
               uiResult.text += arrayCollection[i] + "n";
   <s:VGroup paddingTop="20" paddingBottom="20"
         paddingLeft="20" paddingRight="20" height="100%">
      <s:Button label="Use SortingCollator" click="setCollator(true)"/>
      <s:Button label="Use MatchingCollator" click="setCollator(false)"/>
      <s:TextArea id="uiResult" height="100%"/>

More content into more languages!

This article was originally written in English. Text in other languages was provided by machine translation.

With all the internet chatter about Google’s decision to end their free machine translation (MT) API and transition to a paid service, some of you may be curious what role machine translation plays at Adobe.

Adobe does not currently integrate Google’s API into any products so we are not directly affected by this change. But we do license machine translation technology from commercial vendors and we are actively investigating ways to leverage MT throughout the company.

Adobe has a market presence in over 30 different languages, so any bit of documentation produced in English potentially multiplies out to a considerable cost if translated into all of those languages. Likewise, every day the company receives incoming communication in the form of emails, testing feedback, and customer service inquiries in even more languages!

To help manage this communication both directions, the Globalization Group at Adobe has turned to machine translation technology. The first step has been to insert MT into the document translation process. Instead of sending documentation out for translation from scratch, we first run the text through MT engines that have been customized for Adobe terminology, and then have our translators post-edit the output. Doing so, we see a speed-up of up to 50% with greater terminological consistency.

Right now, about 20 products are using MT for at least one language — including Photoshop, Acrobat, and Illustrator — and the list is expanding each month.

And the story doesn’t end there!  We are actively working on other ways to leverage MT to improve our ability to serve and communicate with a worldwide audience. Watch this blog as we gradually roll out new initiatives in the coming months!

— Raymond Flournoy
Senior Program Manager, MT Initiatives
Translation Technology Team

Localized Platform ActionScript Reference

This article was originally written in English. Text in other languages was provided by machine translation.

The Adobe® Flex® ActionScript® 3.0 Language Reference in 6 languages is no more; the ActionScript® 3.0 Reference for Adobe® Flash® Professional in 16 languages bit the dust as well. Before you panic, the localized ActionScript References have gone the route of the English-language ActionScript® 3.0 Reference for the Adobe® Flash® Platform.

Announcing! The Platform ASR, as we affectionately call it, is now available in all 16 languages of the Flash Platform: English, French, German, Japanese, Korean, Simplified Chinese, Traditional Chinese, Spanish, Italian, Dutch, Brazilian Portuguese, Swedish, Russian, Turkish, Polish and Czech!

In addition to English, commenting has been enabled for French, German, Japanese, Spanish, Italian, Dutch, Brazilian Portuguese, and Simplified Chinese.

Now, if you develop in Flex, ColdFusion and Flash, in a language other than English, let’s say Japanese, you will be able to filter on those products and get the AS classes you need, all in one single document!

Not all products are supported in every language, but the beauty of this “all products under one roof” scenario is that you won’t have to go back and forth between the English-only version and a localized version if you are, for example, a Flex and ColdFusion developer. That’s because, for those products not supported in a particular language, you will find the English default in the same document. For example, French is supported by Flash Pro, AIR, Flash Player, Flex, but not LiveCycle or ColdFusion. So, in the French Platform ASR, you will find French and English together, depending on which products or runtimes you filter on.

The URLs to each language, for your convenience:

I hope you are as excited about this as I am. Please blog and tweet about it, but most importantly, start using the new Platform ActionScript Reference in one of the above languages! Let me know what you think.

[Janice Campbell, Platform Localization]

Adobe AIR Launchpad Localized

This article was originally written in English. Text in other languages was provided by machine translation.

Adobe AIR Launchpad v2.5.0, the desktop tool (created by Platform Evangelist Greg Wilson & team) that helps Adobe Flex® developers get started building desktop and mobile applications deployed on Adobe AIR, is now available in seven new languages in addition to English: French, Spanish, German, Portuguese, Russian, Chinese, and Japanese.

For details about the Launchpad v2.5.0 new features, including the localizations, visit Holly Schinsky’s (aka devgirlFL) blog. The language used at runtime is determined based on the default OS language. So far, feedback has been positive. If you wish to help us improve on it, please post to the AIR Launchpad Forum.

Thanks, the Flex Localization Team

The Localization Wall

This article was originally written in English. Text in other languages was provided by machine translation.

Des Oates
Localization Solutions Architect

I first got involved in the localization industry when I joined Aldus Corporation in Scotland in early 1994 shortly before it became part of Adobe. Kurt Cobain was still rockin ‘n rollin. Bill Clinton had just completed his 1st year of his 1st term and D:Ream were top of the UK music charts with ‘Things Can Only Get Better’. A prophetic anthem for todays article.

Back then Aldus’ European localization team comprised of a group of  around 40-50 in-house staff comprising of  Localization Engineers, QE,  Linguists, Graphics/DTP Professionals, Planners and Researchers. A grand assembly for sure. But as I recall our delivery capabilities were not quite so grand: For a typical software release, a localization project would:

  • Target no more than 10 target languages in total
  • Have no more than 2 or 3 languages actively worked on at any time
  • Be the only major software release worked on at that time
  • Employ little or no external partners
  • Take up to 9 months to complete large projects.

Nine months to localize one product in 10 languages. Seriously?  NASA can get a robots to Mars faster!

Contrast this to today. In Spring 2010 we released Adobe Creative Suite 5.0 :

  • 5 Suite Versions.
  • 15 individual products
  • 24 languages

Over 600 localized applications simshipped* with English, with 50% bug reduction over the previous release. I think you’ll agree it’s an incredible step up from the old days.

Nowadays Adobe Globalization group is slightly larger than it was back then. We focus mostly on Program Management, Globalization/Engineering Leadership and International QE. Almost everything else is handled by trusted partners. We are always looking to improve our productivity, quality, and global reach. As such we’ve made a lot of changes over the years to our processes our staff and our technology. It’s hard to capture all the changes we’ve made succinctly in a article like this, but based on this experience, I thought I’d share some lessons we’ve learned along the way.

The biggest changes we have made are in these interdependent areas: Architectural, technical, and cultural. Here’s some key points:

  • Internationalization. If done well initially, the localization benefits (financial and time-to-market) will outweigh up front the costs by an order of magnitude. Evangelizing best I18n practices for your technology is also a worthwhile endeavour. Internationalization support should be a key criterion when deciding on your development platform for your project.


  • Automation. We are always striving to improve localization automation in our business. Don’t think of localization as a human process. It doesn’t have to be. It could be a series of automated steps, one or more of which may require some human translation input. As a rule of thumb, the more manual steps you have in your localization process, the costlier it will be.  Whether you use a GMS, a bespoke system, or just a bunch of scripts- it doesn’t matter.  You will reap productivity rewards and reduce costs if you employ reliable, maintainable and repeatable automation.


  • Release/Build Integration. In the old days, our Localization Engineers built every component of the localized software that went on the CD manually on their own workstation. It was error-prone, and labor-intensive and required a lot of QE. Now all application language versions are built as part of a unified process. Localization has become simply a release engineering sub-process, allowing us to scale up our efforts dramatically. If you first optimize your automation, it makes sense to integrate the process into a single multilingual release configuration.


  • Trusted/Trusting Partners: The final area of change was the way we interacted with other groups.  We identified cultural and communication barriers between us and the groups we work with. Ultimately you need to establish trusted effective partnerships with the stakeholders in your localization processes. It may be internal teams such as development teams or business units that you need to reach out to, or external partners such as LSPs or translation providers.


Here at Adobe we started the ‘World Readiness’ programme: An initiative lead by my colleague Leandro Reis which provides an assessment framework to evaluate the global-readiness of our products. Along with highlighting the problems it offers advice and expertise on how to fix them. Our internal ‘customers’ were compelled by this approach, and our internal localization walls began to fall.

Similarly if you use external partners, they should be willing and capable of integrating with your business – not vice versa. That may require some initial training and ongoing mentoring. It’s easy decide not to do this, to keep the localization wall high between you and your partners, throw localization work back and forth over it but that model is ultimately more costly. The lack of transparency can lead to project overruns, increased defect rates, and occasionally chaos. However if you streamline your own localization processes, lower your localization walls and select competent partners willing to embrace your business processes, then you will gain a trusted capable partner, and your partners will gain a high-value, repeat-business client.  A win-win situation.

Just for fun I looked up  the number 1 song  in the UK charts when Adobe customers across the globe started receiving their localized copies of Creative Suite 5 in May 2010…

…”Good Times” by Roll Deep.


* simship: No more than 5 days after English


How to create a localized DateChooser in your Flex app

This article was originally written in English. Text in other languages was provided by machine translation.


Xie Fang

By default the DateChooser in Flex shows the English UI. You need to set the dayNames and monthNames properties to localized strings so that it shows the language you want. But do you know that all these localized names are available in the flash.globalization package? Here’s how to get the localized names.

First, create a DateTimeFormatter object with the locale you are interested in the <fx:Script> section

Alternatively, if you feel more comfortable with MXML than ActionScript, you can use a MXML DateTimeFormatter in the <fx:Declarations> section.

Second, create a vectorToArray function for type conversion in the <fx:Script> section, we will explain a little more in the next step.

Third, in your <mx:DateChooser> component, set the dayNames and monthNames properties.

And since you are using the DateTimeNameStyle enums, you want to import them in <fx:Script>

Here, the getWeekdayNames and getMonthNames methods give the localized names as a vector of string. And vectorToArray function is used to convert them to array before assigning them to the DateChooser. The getFirstWeekday method gives the first day of the week for the locale. For example, many european locales use Monday as the first day instead of Sunday.

That’s it. Now run your app and you will see the DateChooser UI is showing in Chinese.

Change the locale to British English (en-GB) and Arabic, Saudi Arabia (ar-SA) to see how the locale changes the first day of week.

Think that this doesn’t save time than hardcoding? Such as:

It is true if you just need to localized to your language. But imagine you need to localize in multiple languages, or languages you don’t know, or you want language switchable by users at run time. Using flash.globalization is more scalable.

To learn more features provided by flash.globalization package, check out the ActionScript API documentation.

A Editora Globo Vai Usar a Adobe Digital Publishing Suite

Este artigo foi originalmente escrito em Português. Qualquer texto em outro idioma foi fornecido via tradução automática.

Editora Globo, o departamento de publicação da Organização Globo — um dos maiores conglomerados de mídia maiores na América Latina — escolheu a Digital Publishing Suite para publicar suas revistas. Localizada no Brasil, a Editora Globo já publicou a revista AutoEsporte usando a solução da Adobe. Agora, a editora planeja usar a Digital Publishing Suite para suas outras revistas, inclusive a revista semanal Época, bem como outras revistas de língua portuguesa como Época Negócios (negócio) e Galileu (ciência e tecnologia).

Para entender porque a Globo decidiu utilizar a Digital Publishing Suite como padrão, contatei Alexandre Maron, Diretor de Inovação Digital na Editora Globo. “A Digital Publishing Suite foi uma escolha natural com a estratégia de publicação da Globo,” escreveu Maron. “O Brasil é um dos países emergentes mais rápidos quanto a mídia digital. Queremos estar na vanguarda em termos de publicação e distribuir revistas digitais, e a integração avançada da Digital Publishing Suite com os nossos sistemas de publicação ajuda-nos a a alcançar estes objetivos — ao mesmo tempo, mantendo uma relação próxima com os nossos leitores.”

Folheei rapidamente páginas de algumas edições da AutoEsporte e uma determinada parte do conteúdo chamou a minha atenção. Normalmente, seria uma parte de interatividade ou um layout meticulosamente trabalhado que notaria, contudo, desta vez foi uma carta ao editor. Ilustrando a capacidade de revistas digitais em cativar o público, um leitor escreveu o seguinte: “Confesso que nunca fui leitor da AutoEsporte, mas a tentação de ver a revista no meu novo iPad foi grande.” “Vocês ganharam um cliente leal que, antes mesmo de terminar esta edição, já está esperando ansiosamente pela próxima.”

Baixe a revista AutoEsporte na App Store

Tradução do artigo: Adobe Digital PublishingBrazilian Publisher Editora Globo to Use Digital Publishing Suite