perldoc2-developers

[perldoc2-developers] General Questions

[Robert 'p. S. <rs...@47...>]

Good evening again, everyone;

If I understood Joergen correctly at the last Hamburg.pm meeting, he's
going to write up a specification on what the application should be doing=
,
on the workflows and what the overall ideas are. So this is just a bunch
of general questions I'd like to bring into discussion.

* Service or Application?

Is the application itself thought as a service to the perl community,
hosted probably under the *.perl.org domain space, or should we focus on
building a standalone-capable application and tools to work with it? As a
simple service focused on translation of the perl documentation, it is
probably easier to handle, but the standalone package way would also have
some advantages. Especially that other projects can use this technology
for providing a translation facility for their documentations. I'd think
of things like Plagger, Catalyst, DBIx-Class and other projects with a
potentially large international target group. This might also have some
implications on the spec though, as a method to refactor larger parts of
the docbase might be helpful, even if perldoc itself is not really
affected by this phenomenon.

* Which Platform?

This question is rather web-development-wise. Personally, I'm pretty much
favoring Catalyst these days. But I might be the only one accustomed to
this framework in here. As I see it, there would be various possibilities
(Catalyst, Maypole, Jifty, CGI-Application, plain CGI, and probably
others). So, what's the plan in this regards, and how do you guys see
this?


Ok, it's been just two questions, but maybe someone else has something to
add :)

gr.,
Robert

--=20
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail =3D> ' rs...@47... ', Web =3D> ' http://474.at ' }

Re: [perldoc2-developers] General Questions

[Joergen W. L. <joe...@gm...>]

Hi everybody,

sorry for being so quiet over the weekend. I was attending to my other 
job as a musician. Just back this morning 04:30 CET. Had to get some sleep.

I will try to answer/comment on your postings as neccessary over the 
next couple of days, so please stay tuned.

Robert 'phaylon' Sedlacek schrieb:
> Good evening again, everyone;
> 
> If I understood Joergen correctly at the last Hamburg.pm meeting, he's
> going to write up a specification on what the application should be doing,
> on the workflows and what the overall ideas are. So this is just a bunch
> of general questions I'd like to bring into discussion.

Correct. I have scheduled the write-up for today.

> * Service or Application?
> 
> Is the application itself thought as a service to the perl community,
> hosted probably under the *.perl.org domain space, or should we focus on
> building a standalone-capable application and tools to work with it? As a
> simple service focused on translation of the perl documentation, it is
> probably easier to handle, but the standalone package way would also have
> some advantages. Especially that other projects can use this technology
> for providing a translation facility for their documentations. I'd think
> of things like Plagger, Catalyst, DBIx-Class and other projects with a
> potentially large international target group. This might also have some
> implications on the spec though, as a method to refactor larger parts of
> the docbase might be helpful, even if perldoc itself is not really
> affected by this phenomenon.

The initial idea was to have a platform dedicated mainly (but not 
exclusively) to the perl community. So to prepare the project for future 
growth and extensibility it is probably the wiser choice to go more for 
the "application" way of things.

I think, generally it is a good idea to be as open to other projects as 
possible. On the other hand, there is Rosetta 
(https://launchpad.net/rosetta) which aims at more or less the same 
goals (and also uses gettext/.po). It already has a huge user/translator 
base plus *very* solid funding. Rosetta is part of the Ubuntu project.

The major difference between Rosetta and our project is our focus on 
documentation rather than dialogues, program messages, etc.

Having said this, I guess that Rosetta can still be a good source of 
inspiration. Analyzing their approach is another piece of work I will 
have to do...

As for the hosting I agree with ask Bjoern Hansen who is responsible for 
perl.org. He said:

   "I think the *.perldoc.perl.org sites should be the
    finished copy for end-users in all cases though;
    the translation tools can run anywhere."

(I was asking about a possibility to have language specific subdomains 
like 'fr.perldoc.perl.org')

Interestingly enough we actually have a working platform already: the 
SVN repository on sourceforge. It is just not really useable by 'end 
users', aka translators.

Frank Seitz of Hamburg.pm suggested a while ago a database driven 
approach. That might be more maintainable/extensible than the SVN-based 
approach.

Any SQL experts around?

> * Which Platform?
> 
> This question is rather web-development-wise. Personally, I'm pretty much
> favoring Catalyst these days. But I might be the only one accustomed to
> this framework in here. As I see it, there would be various possibilities
> (Catalyst, Maypole, Jifty, CGI-Application, plain CGI, and probably
> others). So, what's the plan in this regards, and how do you guys see
> this?

As the platform (or - at least the 'interface') will be mostly web-based 
this is going to be a key decision. I think the choice should be based 
on the following:

- extensibility
   (add natural and programming languages, subprojects...)
- maintainability
   (database, forums, resources)
- security
   (the more people use it, the bigger the chance that someone
   breaks it accidentally)
- stableness
   (same as above)
- simpleness
   (both in structure as in useability)

> Ok, it's been just two questions, but maybe someone else has something to
> add :)

Only two - but two *very important* questions. Thanks, Robert.

As I said, I will try to come up with some ideas by tomorrow.

Greetings to y'all,

Joergen

Re: [perldoc2-developers] General Questions

[Robert 'p. S. <rs...@47...>]

Hello Joergen, 'evening .*

Joergen W. Lang said:
> Robert 'phaylon' Sedlacek schrieb:
>
>> * Service or Application?
>
> The initial idea was to have a platform dedicated mainly (but not
> exclusively) to the perl community. So to prepare the project for futur=
e
> growth and extensibility it is probably the wiser choice to go more for
> the "application" way of things.
>
> I think, generally it is a good idea to be as open to other projects as
> possible. On the other hand, there is Rosetta
> (https://launchpad.net/rosetta) which aims at more or less the same
> goals (and also uses gettext/.po). It already has a huge user/translato=
r
> base plus *very* solid funding. Rosetta is part of the Ubuntu project.
>
> The major difference between Rosetta and our project is our focus on
> documentation rather than dialogues, program messages, etc.
>
> Having said this, I guess that Rosetta can still be a good source of
> inspiration. Analyzing their approach is another piece of work I will
> have to do...

Well, I actually had only the perl community in mind at first, as most of
them will have documentation in POD format.

> Interestingly enough we actually have a working platform already: the
> SVN repository on sourceforge. It is just not really useable by 'end
> users', aka translators.
>
> Frank Seitz of Hamburg.pm suggested a while ago a database driven
> approach. That might be more maintainable/extensible than the SVN-based
> approach.
>
> Any SQL experts around?

It all depends on what we "want to do." Personally, I'd ++ a database
approach with a, for example, shipped DBIC model that's ready to use. Thi=
s
would allow 3rd parties to develop tools which can flow back to the
project.

What approach or schema to take depends on the data structure. What atoms
are there for checkout/editing/comparing/merging/etc? What workflows have
to be there, which states have to be kept?

> As the platform (or - at least the 'interface') will be mostly web-base=
d
> this is going to be a key decision. I think the choice should be based
> on the following:

As I'm really only familiar with Catalyst, I'll focus my answers in this
part on it.

> - extensibility
>    (add natural and programming languages, subprojects...)

What do you mean by "subprojects"? Most Perl Frameworks will provide
support for Unicode and I18N/L10N. And if we focus on po4a as input
format, we have a common middle ground that can be targetted by other
documentation projects/formats.

> - maintainability
>    (database, forums, resources)

Catalyst itself is database-agnostic. Personally I'd favor DBIC, as it is
pretty expressive, powerful, and has a very active community. I'm not so
sure what you mean with forums and resources. Does CPAN count for the
latter?

> - security
>    (the more people use it, the bigger the chance that someone
>    breaks it accidentally)

Well, if we don't eval, check all incoming user data, use database access
based somehow on DBI and it's binding mechanisms, we should be on a save
side. Fortunately, we have no register_globals :)

> - stableness
>    (same as above)

I can't really remember any stability issues with the current popular Per=
l
web frameworks, anyway.

> - simpleness
>    (both in structure as in useability)

Good point. I'd like to add deployability, where Catalyst itself has pro'=
s
and con's. The con part is it's huge list of dependencies, but that can
(in a ready application) be shipped with, either in a distribution or in =
a
PAR file, which should be able to capture the whole perl deployment
environment.

Another pro is the possibility of deployment on many engines. mod_perl,
FastCGI, SpeedyCGI, pperl.


Thanks for the answers!
gr.,
Robert

--=20
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail =3D> ' rs...@47... ', Web =3D> ' http://474.at ' }

Re: [perldoc2-developers] General Questions

[Joergen W. L. <joe...@gm...>]

[This (not Roberts preceding) post should be mostly obsolete since most 
of it should be answered in the Specification. Anyway - for 
completeness' sake... here we go:]

Robert 'phaylon' Sedlacek schrieb:

>>> * Service or Application?

>> The initial idea was to have a platform dedicated mainly (but not
>> exclusively) to the perl community. So to prepare the project for future
>> growth and extensibility it is probably the wiser choice to go more for
>> the "application" way of things.

> Well, I actually had only the perl community in mind at first, as most of
> them will have documentation in POD format.

It should be clear by now, that other document formats should be not a 
big problem, thanks to po4a (Nicolas' posting) and CPAN (Herbert's posting).

> It all depends on what we "want to do." Personally, I'd ++ a database
> approach with a, for example, shipped DBIC model that's ready to use. This
> would allow 3rd parties to develop tools which can flow back to the
> project.
> 
> What approach or schema to take depends on the data structure. What atoms
> are there for checkout/editing/comparing/merging/etc? What workflows have
> to be there, which states have to be kept?

see Spec and the following discussion.

>> - extensibility
>>    (add natural and programming languages, subprojects...)
> 
> What do you mean by "subprojects"? Most Perl Frameworks will provide
> support for Unicode and I18N/L10N. And if we focus on po4a as input
> format, we have a common middle ground that can be targetted by other
> documentation projects/formats.

The translation of the "core documentation" is a "subproject" of the 
translation of the Perl documentation, for example. See Spec for details.

>> - maintainability
>>    (database, forums, resources)
> 
> Catalyst itself is database-agnostic. Personally I'd favor DBIC, as it is
> pretty expressive, powerful, and has a very active community. I'm not so
> sure what you mean with forums and resources. Does CPAN count for the
> latter?

I was referring to forums that run on the platform or as part of is. The 
data accumulated by these forums will probably be stored in one or the 
other DB. This DB should be easily maintainable.

With "resources" I meant things like glossaries that might be available 
to transalators or other people. Maybe people could have their own 
glossary or dictionary.

CPAN is a resource but none that is maintained by this project so it 
probably does not count in this context.

>> - security
>>    (the more people use it, the bigger the chance that someone
>>    breaks it accidentally)
> 
> Well, if we don't eval, check all incoming user data, use database access
> based somehow on DBI and it's binding mechanisms, we should be on a save
> side. Fortunately, we have no register_globals :)

-T comes to mind. The things you mention above could probably be 
incorporated in some sort of "coding guideline" for the project. For the 
moment I do not think, we need this, since the people involved had 
enough time to learn from their own mistakes already, right? ;o))

>> - stableness
>>    (same as above)
> 
> I can't really remember any stability issues with the current popular Perl
> web frameworks, anyway.

Do they stay up and running even if one or more required modules fail to 
work (maybe due to an update, API change or whatever)? Especially with 
these huge lists of dependencies this could be an issue. But maybe I'm 
just paranoid.

>> - simpleness
>>    (both in structure as in useability)
> 
> Good point. I'd like to add deployability, where Catalyst itself has pro's
> and con's. The con part is it's huge list of dependencies, but that can
> (in a ready application) be shipped with, either in a distribution or in a
> PAR file, which should be able to capture the whole perl deployment
> environment.

This might be important if we start developing the platform on SF and 
then have to move it to whatever the final destination might be.

> Another pro is the possibility of deployment on many engines. mod_perl,
> FastCGI, SpeedyCGI, pperl.

Agreed.

Joergen

Re: [perldoc2-developers] General Questions

[Robert 'p. S. <rs...@47...>]

Joergen W. Lang said:

> [This (not Roberts preceding) post should be mostly obsolete since most
> of it should be answered in the Specification. Anyway - for
> completeness' sake... here we go:]

I'll concentrate on the points being separate from the spec then :)

> I was referring to forums that run on the platform or as part of is. Th=
e
> data accumulated by these forums will probably be stored in one or the
> other DB. This DB should be easily maintainable.

I'm not sure if it's a good idea to include a bboard into the codebase, a=
s
this just adds up work distracting from the real thing[tm]. For example,
the german perl community has a self written board which is in
re-development. It surely isn't perfect, but it might be fitting for our
purposes.

> With "resources" I meant things like glossaries that might be available
> to transalators or other people. Maybe people could have their own
> glossary or dictionary.

Now I get it. ++ to that then.

> -T comes to mind. The things you mention above could probably be
> incorporated in some sort of "coding guideline" for the project. For th=
e
> moment I do not think, we need this, since the people involved had
> enough time to learn from their own mistakes already, right? ;o))

Guidelines are certainly good. If we want to keep it maintainable we also
shouldn't start adding dependencies like there's no tomorrow. So we might
want to discuss those things separately.

>> I can't really remember any stability issues with the current popular
>> Perl
>> web frameworks, anyway.
>
> Do they stay up and running even if one or more required modules fail t=
o
> work (maybe due to an update, API change or whatever)? Especially with
> these huge lists of dependencies this could be an issue. But maybe I'm
> just paranoid.

That's rather a deployment and development issue imho. We should certainl=
y
do testruns before deploying/updating the main site. Things like PAR coul=
d
also help us with this, as it captures a whole environment (optionally
even including core modules).

> This might be important if we start developing the platform on SF and
> then have to move it to whatever the final destination might be.

Well, SF can't run it anyway, can it? It should be possible for developer=
s
of the platform to check it out and run it on their own systems. Another
neutral systems before regular deployments to the end site would imho be
another good idea, too.

gr.,
Robert

--=20
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail =3D> ' rs...@47... ', Web =3D> ' http://474.at ' }

Re: [perldoc2-developers] General Questions

[Joergen W. L. <joe...@gm...>]

Robert 'phaylon' Sedlacek schrieb:

> I'll concentrate on the points being separate from the spec then :)

[...]

> I'm not sure if it's a good idea to include a bboard into the codebase, as
> this just adds up work distracting from the real thing[tm]. For example,
> the german perl community has a self written board which is in
> re-development. It surely isn't perfect, but it might be fitting for our
> purposes.

Sorry for being so unclear. I did not think of including anything like 
BBoard or Forum capabilities directly into the codebase (that's why I 
put them under "additional features" in the specification, maybe 
should've called them "add-ons" or something...).

We definitely should focus on the creation of the platform itself.

Although I feel that things like a BBoard, forum or whatever means of 
communication are very neccessary features they should not clutter up 
the codebase.

>> With "resources" I meant things like glossaries that might be available
>> to transalators or other people. Maybe people could have their own
>> glossary or dictionary.
> 
> Now I get it. ++ to that then.

:o) There you go.

>> -T comes to mind. The things you mention above could probably be
>> incorporated in some sort of "coding guideline" for the project. For the
>> moment I do not think, we need this, since the people involved had
>> enough time to learn from their own mistakes already, right? ;o))
> 
> Guidelines are certainly good. If we want to keep it maintainable we also
> shouldn't start adding dependencies like there's no tomorrow. So we might
> want to discuss those things separately.

Sorry, not clear. What do you mean by "dependencies" is in this context?

> [stability issues]
> 
> That's rather a deployment and development issue imho. We should certainly
> do testruns before deploying/updating the main site. Things like PAR could
> also help us with this, as it captures a whole environment (optionally
> even including core modules).

Or one step further - and you have something like apachefriends.org's 
XAMPP project.

>> This might be important if we start developing the platform on SF and
>> then have to move it to whatever the final destination might be.
> 
> Well, SF can't run it anyway, can it? It should be possible for developers
> of the platform to check it out and run it on their own systems. Another
> neutral systems before regular deployments to the end site would imho be
> another good idea, too.

Well - there's webspace, there's perl, there's shell access - what else 
do we need? Apart from that I do agree to the point of checking out and 
testing locally.

BTW - There's plenty of space on my server... :o)

Joergen

Re: [perldoc2-developers] General Questions

[Robert 'p. S. <rs...@47...>]

Joergen W. Lang said:

> Sorry for being so unclear. I did not think of including anything like
> BBoard or Forum capabilities directly into the codebase (that's why I
> put them under "additional features" in the specification, maybe
> should've called them "add-ons" or something...).

How about "infrastructure"? :)

> Although I feel that things like a BBoard, forum or whatever means of
> communication are very neccessary features they should not clutter up
> the codebase.

Sure. The question is more which way to take. Personally, I prefer mailin=
g
lists.

>> Guidelines are certainly good. If we want to keep it maintainable we
>> also shouldn't start adding dependencies like there's no tomorrow. So =
we
>> might want to discuss those things separately.
>
> Sorry, not clear. What do you mean by "dependencies" is in this context=
?

CPAN :) The web frameworks manage their own dependencies pretty well. I
mean we should discuss _which_ XML module we use, _which_ database access=
,
and so on. To keep the dependencies as simple and as communicated as
possible. This should ease deployment too.

>> [stability issues]
>>
>> That's rather a deployment and development issue imho. We should
>> certainly do testruns before deploying/updating the main site. Things
>> like PAR could also help us with this, as it captures a whole environm=
ent
>> (optionally even including core modules).
>
> Or one step further - and you have something like apachefriends.org's
> XAMPP project.

Also a possibility. Although I see the "other projects" and "whole
different languages" target groups more fit to this way of distribution.

>>> This might be important if we start developing the platform on SF and
>>> then have to move it to whatever the final destination might be.
>>
>> Well, SF can't run it anyway, can it? It should be possible for
>> developers of the platform to check it out and run it on their own
>> systems. Another neutral systems before regular deployments to the end
>> site would imho be another good idea, too.
>
> Well - there's webspace, there's perl, there's shell access - what else
> do we need? Apart from that I do agree to the point of checking out and
> testing locally.

Question is which perl, what kind of webspace, how much influence on the
perl environment, etc.

> BTW - There's plenty of space on my server... :o)

Which might be a much better fit. Sidenote: Of course I mean the
translation platform itself, not the hosting of the finally translated
files. For that I'd think a sort of export (e.g. into the projects SVN, s=
o
everyone, including the $lang.perldoc.perl.org space can easily stay up t=
o
date) would be a much better fit for that.

gr.,
Robert

--=20
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail =3D> ' rs...@47... ', Web =3D> ' http://474.at ' }

Re: [perldoc2-developers] General Questions

[Joergen W. L. <joe...@gm...>]

Robert 'phaylon' Sedlacek schrieb:

> CPAN :) The web frameworks manage their own dependencies pretty well. I
> mean we should discuss _which_ XML module we use, _which_ database access,
> and so on. To keep the dependencies as simple and as communicated as
> possible. This should ease deployment too.

I'd prefer an "out of the box" approach as much as possible unless we 
have a really good reason not to.

>>> [stability issues]
>>>
>>> That's rather a deployment and development issue imho. We should
>>> certainly do testruns before deploying/updating the main site. Things
>>> like PAR could also help us with this, as it captures a whole environment
>>> (optionally even including core modules).

>> Or one step further - and you have something like apachefriends.org's
>> XAMPP project.
> 
> Also a possibility. Although I see the "other projects" and "whole
> different languages" target groups more fit to this way of distribution.

That would oppose the "simple" principle, though. After all the 
application itself does not really have to be "distributed", it's the 
services it offers - and they are distributed over HTTP, etc.

[hosting on sourceforge]

> Question is which perl, what kind of webspace, how much influence on the
> perl environment, etc.

perl 5.8.3
Apache 1.3.xx?
...

Well... not very much info.

>> BTW - There's plenty of space on my server... :o)
> 
> Which might be a much better fit. Sidenote: Of course I mean the
> translation platform itself, not the hosting of the finally translated
> files. 

Oh - really? :o)

Let's hope the translated files eventually reside on peoples harddrives 
or under xx.perldoc.perl.org.

> For that I'd think a sort of export (e.g. into the projects SVN, so
> everyone, including the $lang.perldoc.perl.org space can easily stay up to
> date) would be a much better fit for that.

That also should be part of the "workflow" page... more work... oh my!

So far....

Joergen

Re: [perldoc2-developers] General Questions

[Robert 'p. S. <rs...@47...>]

Joergen W. Lang said:
>
> I'd prefer an "out of the box" approach as much as possible unless we
> have a really good reason not to.

Define "out of the box"? No external dependencies? This would be hard.
That's why I proposed using PAR for distribution.

>> Also a possibility. Although I see the "other projects" and "whole
>> different languages" target groups more fit to this way of distributio=
n.
>
> That would oppose the "simple" principle, though. After all the
> application itself does not really have to be "distributed", it's the
> services it offers - and they are distributed over HTTP, etc.

Yes, but as I have stated a few mails earlier, this application would hav=
e
large potencial to be useful for other projects too. Or do you want to
host all possible translation projects on this one server?

>> Which might be a much better fit. Sidenote: Of course I mean the
>> translation platform itself, not the hosting of the finally translated
>> files.
>
> Oh - really? :o)
>
> Let's hope the translated files eventually reside on peoples harddrives
> or under xx.perldoc.perl.org.

This would be the best, yes :)

>> For that I'd think a sort of export (e.g. into the projects SVN, so
>> everyone, including the $lang.perldoc.perl.org space can easily stay u=
p
>> to
>> date) would be a much better fit for that.
>
> That also should be part of the "workflow" page... more work... oh my!

Heh. That cmes with it :)

gr.,
Robert

--=20
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail =3D> ' rs...@47... ', Web =3D> ' http://474.at ' }

Re: [perldoc2-developers] General Questions

[Joergen W. L. <joe...@gm...>]

Robert 'phaylon' Sedlacek schrieb:
> Joergen W. Lang said:
>> I'd prefer an "out of the box" approach as much as possible unless we
>> have a really good reason not to.
> 
> Define "out of the box"? No external dependencies? This would be hard.
> That's why I proposed using PAR for distribution.

If a web-framework already offers the features we need we should not 
reinvent/reimplement without good cause.

>>> Also a possibility. Although I see the "other projects" and "whole
>>> different languages" target groups more fit to this way of distribution.

>> That would oppose the "simple" principle, though. After all the
>> application itself does not really have to be "distributed", it's the
>> services it offers - and they are distributed over HTTP, etc.
> 
> Yes, but as I have stated a few mails earlier, this application would have
> large potencial to be useful for other projects too. Or do you want to
> host all possible translation projects on this one server?

To be honest, I didn't think of this at all. But I can see your point. 
And I do not think, it would add more complexity to the project if we 
keep in mind that it should be portable to other servers, too. Under 
these circumstances apachefriends XAMPP might actually be not so bad at 
all. Did you ever try it? I mean, installing and configuring a LAMP by 
hand *can* be tedious. XAMPP does it in a few minutes.

>>> Which might be a much better fit. Sidenote: Of course I mean the
>>> translation platform itself, not the hosting of the finally translated
>>> files.

>> Oh - really? :o)
>>
>> Let's hope the translated files eventually reside on peoples harddrives
>> or under xx.perldoc.perl.org.
> 
> This would be the best, yes :)

Basically we have "go" for finished translations of the "actual" version.

>>> For that I'd think a sort of export (e.g. into the projects SVN, so
>>> everyone, including the $lang.perldoc.perl.org space can easily stay up
>>> to date) would be a much better fit for that.

Joergen

Re: [perldoc2-developers] [RFC] Platform Specification Vs. 0.1

[herbert b. <dei...@we...>]

allright, here my cents

#####################
- interface(s)
#####################

so we do it as webapp not desktop, that would be fine since im also involved in several other projects and a tranlation helper is something totally different than the pod viewer i want to build anyway.

#####################
- people
#####################

so we have admins that create and maintain the platform
and 

translators that can be assigned to a whole language a document or as reviewer
more seems to complex for me

sidenote: please don't compare our reviews with wikipedias peer review because wp is
a hack of a mess. sometimes it works well but that depends on subject, weather, 
astrological circumstances and other darker forces, because there is nearly everything 
open. i like to have here a more restricted culture, even if it should be for *ANYONE*
should be as easy as possible to make comments on any translated passage, that can be
considered later by the assigned translators.


#####################
Multiple formats
#####################

we are perl hacker with CPAn on our side so converter tools should be least problem.

#####################
Meta information
#####################

thats no enough, take me for instace, es i wrote my czech is sophisticated but containes
some terrible orthographical flaws (some people here claim that is also true for my german *g* ). such infos i like to atach on a doc that an revisor don't have to search for flaws i know there are at certain words or word group. 
so only mark a block or whole sentences as fuzzy would'nt do it IMO.

in much i agree with robert

so far

herbert

Re: [perldoc2-developers] [RFC] Platform Specification Vs. 0.1

[Robert 'p. S. <rs...@47...>]

herbert breunung said:

> #####################
> - interface(s)
> #####################
>
> so we do it as webapp not desktop, that would be fine since im also
> involved in several other projects and a tranlation helper is something
> totally different than the pod viewer i want to build anyway.

Hmm. I'd propose we factor the domain logic out of the webapplication. So
that the webface is only the interface between checkins, checkouts,
merges, stage changes etc. This would allow an easy implementation of
something along WebServices, XMLRPC, REST, etc.

> #####################
> - people
> #####################
>
> so we have admins that create and maintain the platform
> and
>
> translators that can be assigned to a whole language a document or as
> reviewer
> more seems to complex for me

Why is it too complex? And what parts exactly? I'd rather think it
shouldn't be too simple, as we have different target audiences and
shouldn't build up barriers.

> even if it should be
> for *ANYONE*
> should be as easy as possible to make comments on any translated passag=
e,
> that can be
> considered later by the assigned translators.

That's for some reason an obviously good idea. The commenting possibility
I mean. As said, I'd differentiate between comments and errata (the latte=
r
being kind of advanced comments). I thought about a ticketized system
because of the history effect and the minimization of duplicate efforts.

> #####################
> Multiple formats
> #####################
>
> we are perl hacker with CPAn on our side so converter tools should be
> least problem.

Full Ack. All the codebase are belong to us. :)

> #####################
> Meta information
> #####################
>
> thats no enough, take me for instace, es i wrote my czech is sophistica=
ted
> but containes
> some terrible orthographical flaws (some people here claim that is also
> true for my german *g* ). such infos i like to atach on a doc that an
> revisor don't have to search for flaws i know there are at certain word=
s
> or word group.
> so only mark a block or whole sentences as fuzzy would'nt do it IMO.

Yea, but it seems easier for translators to reject complete blocks or
paragraphs, but _with comments and reasoning_. As sometimes it's not just
a fuzzy word, but it's context, the sentence around it, and other things
which might be reconsidered to make it more fitting.

> in much i agree with robert

Always a good thing! *scnr* ;)

gr.,
Robert

--=20
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail =3D> ' rs...@47... ', Web =3D> ' http://474.at ' }