Hi HF,
Limited support is available. In order to view Galaxy in other languages, you
need to set the language preference in your browser to e.g. Japanese. Chrom,
for example, allows you to set up a priority ordered list of prefered
languages, so you'll have to set Japanese to the top of the li
To clarify a bit more, there are currently only 2 languages supported in the Galaxy distribution; English and Japanese (note the 'en' and 'ja' subdirectories in the 'locale' directory). Setting your preferred language in your browser to Japanese will only render some Galaxy content in Japanese. T
I agree with the risks you cited.
There is a risk in the other direction that I think is even scarier - without
the ability to add data types, tool authors may be forced to use a "typeless"
system, declaring all inputs/outputs as "data" or "text". While this works, it
has the same drawbacks as
On Mon, Oct 10, 2011 at 2:39 PM, Greg Von Kuster wrote:
>
> To clarify a bit more, there are currently only 2 languages
> supported in the Galaxy distribution; English and Japanese ...
Is it possible for tool wrappers to embed alternative language text?
Peter
On Mon, Oct 10, 2011 at 5:09 PM, Duddy, John wrote:
> I agree with the risks you cited.
>
> There is a risk in the other direction that I think is even scarier -
> without the ability to add data types, tool authors may be forced
> to use a "typeless" system, declaring all inputs/outputs as "data"
There are a number of well defined formats that are exchanged between
applications, e.g. BAM, gtf, etc, I wouldn't advocate proliferating those.
I see the need for Toolshed datatypes more for the intermediate file formats
used within a suite of commands. These can be helpful in guiding a us
I don't think our locale support works with Cheetah, but it's been quite some
time since I've worked in this area, so I may be wrong. Most of the magic
happens in the GalaxyWebTransaction.setup_i18n() method in
~/lib/galaxy/web/framework.__init__.py which is mako centric. It shouldn't be
too
Hello Florent,
On Oct 4, 2011, at 11:42 PM, Florent Angly wrote:
> Hi Greg,
>
> Thank you for your help. Your suggestion worked like a charm!
>
> I was expecting to see an error because I did not create the ../shed_tool/
> folder that contains the tools installed from the shed, but I was happy
Peter has the right idea here - we will add support for appropriate data types
to the Galaxy distribution. Of course, the key word here is "appropriate", but
any industry-standard data format should fall under this category.
On Oct 10, 2011, at 12:46 PM, Peter Cock wrote:
> On Mon, Oct 10, 201
Hello Jim,
On Oct 10, 2011, at 1:01 PM, Jim Johnson wrote:
> There are a number of well defined formats that are exchanged between
> applications, e.g. BAM, gtf, etc, I wouldn't advocate proliferating those.
>
> I see the need for Toolshed datatypes more for the intermediate file formats
> u
Hello!
If I setup a private cloud infrastructure with ubuntu, can I setup galaxy
cloudman there?
Thanks!
Rodrigo
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and ot
David,
I'm cc'ing the galaxy-dev mailing list; let's keep this thread on the list for
archival and community purposes.
>
>> I had a look through the Trinity.pl script and found that the default
>> butterfly
>> heap is set to 1G.
>>
>> I've changed this to 2G. Would you re-run the trinity job
It works when I set Japanese as the preferred language.
I saw these lines in ginga.po under the folder
galaxy-dist/locale/jp/LC_MESSAGES
#: tools/**.xml
#: tool_conf.xml
msgid "Get Data"
msgstr "データ取得"
msgid "Get ENCODE Data"
msgstr "ENCODEデータ取得"
msgid "ENCODE Tools"
msgstr "ENCODEツール"
But
13 matches
Mail list logo
