similar to: UTF8 and I18n for theoracomment

Hi there, the attached patch for theora-tools adds UTF8 support to theoracomment; however, for this I did copy some "shared" files from vorbis-tools to theoracomment. I'm not sure whether you want this but rather make them shared in theora-tools, too? Additionally, I added header-comments in the style of theoraenc and a manpage. So far, theoracomment looks rather complete now

Hi all, I've attached a SVN diff for theora-tools, adding a simple "theoracomment" utility; it is intended to be the counterpart of vorbiscomment for theora/vorbis-ogg-files. It shares vorbiscomment's usage/features (and the frontend-code). While the main functionality is already there, there are still some restrictions: * No support for chained streams * It simply uses

Sounds good! Though maybe calling it oggz-metadata might make more sense? Cheers, Silvia. On Sun, Jun 13, 2010 at 1:42 PM, VolodyA! V Anarhist <Volodya at whengendarmesleeps.org> wrote: > Hi, > > I've sent one of these before, but i wasn't subscribed, and i'm unsure if it > went out. I'm subscribed now and i've written another (i believe) nifty > wrapper

Hey all, I'm working on a media-database art project that basically stores a bunch of sound and video files, which are then navigated based on meta-data. I'm not sure where to start asking these, questions, here seemed like a good start. So I was thinking I should use an open format, like ogg/vorbis/theora. I also thought, will all that coll meta-data stuff in ogg I should be able to

Hello. Attached are some patches that some Debian users of vorbis-tools have sent to our BTS over the years (numbers refer to Debian bugs). It'd be nice to see them integrated. They apply cleanly to SVN as of today. The largefile_support one is a bit bigger than just the configure.ac since the submitter adviced that config.h got included in all C source files before the standard includes,

Hello. Attached are some patches that some Debian users of vorbis-tools have sent to our BTS over the years (numbers refer to Debian bugs). It'd be nice to see them integrated. They apply cleanly to SVN as of today. The largefile_support one is a bit bigger than just the configure.ac since the submitter adviced that config.h got included in all C source files before the standard includes,

Hi, I've sent one of these before, but i wasn't subscribed, and i'm unsure if it went out. I'm subscribed now and i've written another (i believe) nifty wrapper for oggz-tools. oggz-comments - allows a user to pass the plain text file with each tag on their own line theoracomment - works like 'vorbiscomment' from VorbisTools package, but sets comments for the

Using metaflac (1.0.3) like this: metaflac file.flac --set-vc-field=title=test??????e? The vorbiscomment will not be UTF8-encoded, instead they will be stored directly as ANSI. When trying to add some more comment, it gave the following error: ERROR: writing FLAC file file.flac, error = FLAC__METADATA_CHAIN_STATUS_OK Does that mean that weren't enough room for the comments? But

--- Mattias Dahlberg <mdati00@student.vxu.se> wrote: > Using metaflac (1.0.3) like this: > > metaflac file.flac --set-vc-field=title=testÅÄÖåäöeè > > The vorbiscomment will not be UTF8-encoded, instead > they will be stored directly as ANSI. yes, metaflac is currently not doing utf-8 encoding. the same libutf8 from libvorbis is in the flac source tree but it's not

On Dec 05 20:16:47, hans at stare.cz wrote: > This is 1.3.1 on OpenBSD/amd64. > The --no-utf8-convert option of metaflac(1) does not work for me: > > $ metaflac --no-utf8-convert --set-tag="Artist=?ou?l??ek" aladin.flac > aladin.flac: ERROR: tag value for 'Artist' is not valid UTF-8 > (You probably can't see the Czech letters properly in my mail, > but

Brian Willoughby wrote: > Jan Stary wrote: >>> This is 1.3.1 on OpenBSD/amd64. >>> The --no-utf8-convert option of metaflac(1) does not work for me: ... >> The problem seems to be in >> src/metaflac/operations_shorthand_vorbiscomment.c >> in the set_vc_field() function. > By the way, I've never used FLAC inside Ogg Vorbis. > Instead, I use pure

I have an application that uses I18n, but in the first deployment, I don''t want to enable different languages per user/request because there are very few users who all speak german). Therefore I have config.i18n.default_locale = :de in config/ application.rb. I have no code whatsoever to set/change I18n.locale in my app. In development environment, it works as expected: the

Hi all, I have 2 linux distro ?? ubuntu and centos. My problem is that the sort command has different behavior when sorting Chinese string encoded in utf8 file. On Ubuntu, it is OK. But on CentOS, it WRONG. I google this problem and it seems that's because of LC_COLLATE. So I change "/etc/sysconfig/i18n" on CentOS and now the 2 have the same LC_** like this: CentOS:

Hello all, I''m trying to translate my application using the I18N feature and it was working fine until I added a couple of new entries to the en.yml files. Now in every action in my application I always get the following error: TypeError in Account#login Showing app/views/account/login.rhtml where line #2 raised: allocator undefined for Proc Extracted source (around line #2): 1: 2:

Hi all, Just wondering... Are there any plans to include i18n support in Rails anytime soon? I guess this is about the only feature I''m realy missing in Rails. Any thoughts? Regards, Harm de Laat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060130/63681052/attachment.html

Because of a folder display problem caused by certain character encodings used in some email headers we had previously updated to squirrelmail-1.4.6-1 and installed squirrelmail-i18n-1.4.6-1 to cope. Yum is now trying to update our installation with the latest offical Centos release but there does not seem to be a corresponding squirrelmail-i18n rpm available in any of the repositories which is

Hi, Im using route_translator gem, which is really great, but unfortunatly Im stuck because special caracters are not recognized. for instance for page /ru/войти , I have this error message No route matches [GET] "/ru/%D0%B2%D0%BE%D0%B9%D1%82%D0%B8" same for french special caracters like "è" . for /fr/dernière , No route matches [GET]

ActiveRecord validation messages are currently not I18N-friendly. Specifically, I''m referring to the fact that it enforces a certain grammar, namely the beginning of the message must consist of the field name. For example: validates_presence_of :name, :message => "can''t be blank." ...generates the message "Name can''t be blank". This grammar

Hello, I was investigating solutions for i18n with will_paginate and I found a possible solution at http://lawrencesong.net/2009/01/enable-i18n-in-will_paginate-plugin/ The author adds to application_helper.rb the following code: ############################################# include WillPaginate::ViewHelpers def will_paginate_with_i18n(collection, options = {})

Hi, to avoid putting the whole locale scope on every I18n.t call I''m trying to use a scope, as stated in the doc (http://guides.rubyonrails.org/active_support_core_extensions.html#with_options) I tried with <%= I18n.with_options :locale => :en, :scope => ''portal.visitor_menu'' do |i18n|%> Try <%= i18n.t :fav_songs %> <% end %> But it produce