[Pangloss] Functional spec

Steve Purkis spurkis at mkdoc.com
Tue Apr 8 13:31:28 BST 2003


Hi Dan,

Thanks for the feedback.

On Monday, April 7, 2003, at 05:51  pm, Dan McQuillan wrote:

> USER?
> my main query is: who is the ordinary User?

Anybody browsing the web.


> i think i'm not sure because for multikulti keywords are currently a 
> 'behind
> the scenes' matter between administrator, translator & proofreader.
>
> are you imagining pangloss being a general feature of a site that a 
> user can
> interrogate seperate of any specific translated text?

Yes, I was.  But we can change that if you like.


> if so i have 2 points:
> - for multikulti, the translations of the keywords may be an important
> resource for our sustainability, so we might want general access to the
> keywords to be by subscription.
> (from your spec i understand that a user would still have to have 
> priviliges
> to access the keywords)

Fair enough - we can restrict access to registered users.  This should 
be an optional feature though, as others using Pangloss may want the 
system to be open.

I'll add:
   "General access may be restricted to a predefined list of users."


> - we might consider tagging the keywords by subject area, and for this 
> to be
> a filter for a search
>
> SUBJECT TAGGING?
> Tagging by subject area could also be useful for translators.
> i'm imagining it might be useful for a translator to see, for example, 
> all
> health terms, in case there's anything in the list that would give them
> ideas on how to translate a new but related term.
> I'll check this out with Njomeza and see what she thinks.

This isn't a requirement I was aware of, but seeing as it should be 
trivial to add in I can do so if you like.  Would it be something that 
is controlled by the administrator, or an arbitrary text field, or 
something else?


> LONG VERSIONS?
> Another thought is whether we should expand the definitions to 
> short-version
> and long-version.
> The short-version would be the one that replaces the English term in 
> the
> text itself. The longer version might be a more heuristic explanation.
> I'll also ask Njomeza about whether she thinks this is a good idea.
> It may not be important/necessary, as currently we're only paying
> translators to translate keywords, not to write an essay about each 
> one ;-)

We imagined a 'notes' field for each keyword / translation that would 
be used by the Proof Reader & translator.  Would this be sufficient?


> GENERATING GLOSSARIES?
> i don't understand the fisrt part of sction 1.4
> "A glossary will be generated based on the user's navigation / search
> through the site."
> can you explain a bit more please.

Sure - the whole point of Pangloss is to generate glossaries.  There 
are 3 main ways of doing this:

   1	navigation based on languages, users and such
   2	searching keywords
   3	submitting a url

As Jean-Michel (& Patrick?)'s initial HTML mock-up suggested:
	+------------------------------+
	| search: _____   url: _____   |
	+-------------+----------------+
	| Language    | Glossary       |
	|   en        |                |
	|   fr        |    keyword 1   |
	|   es        |    keyword 2   |
	|             |    .           |
	| Translator  |    .           |
	|   fred      |    .           |
	|   bob       |                |
	|             |                |
	+-------------+----------------+

As you navigate or search through, the glossary on the right would 
change.  If you had entered a URL, you may or may not want to loose the 
left-hand pane - it's up to you.

At any rate - I'll combine "1.3 Navigation" with "1.4 Glossary" and 
include a better description.


> For the second part, where the glossary is generated via a submitted 
> URL,
> will the processing of the source text take in to account 
> word-stemming etc?
> (it moght not be exactly the same use of the term in the text).
>
> Also, if we have a word like 'disabled' in the keywords already, and 
> we have
> 'disability' in the new text, would the processing pick that up and 
> give the
> translation of 'disabled' in the glossary?
> (That might be asking a bit much, but maybe not.)

No, we were planning on doing exact/fuzzy matches only.  This would 
catch differences in case and small variations such as typos.  If you'd 
like me to include word-stemming I can investigate it and come up with 
a cost for you.


> OTHER COMMENTS:
> in section 2.4.1, B.4 where is says ".  Pangloss deletes the selected 
> user
> (and all dependencies?) "
> i guess the dependencies is the translations previously done by that 
> user?
> In which case i'd say 'No'. (we want to keep the previous 
> translations).

Fair enough - then it would be a good idea to never delete users, only 
disable them.  We could still have a 'delete' that just marks the 
account as deleted and disables it.

I'll update this.


> For section 2.4.2, B.4
> "Pangloss deletes the selected language (and all dependencies?) and 
> returns
> to (2)"
> i can't think we'd want to delete previous translations for a 
> language, even
> if we stop doing 'live' tranlsations of that language.

What if the admin adds a language by mistake (ie: makes a typo)?  Or 
what if you decide to remove support for a language?  If it only 
deletes the language there would be lots of unusable data lying around 
- translations w/o a language don't make sense.  I don't want to see 
the system generate data that cannot be accessed.


> In section 2.3.1.3 is says "3.Proofreader selects new status (and 
> optional
> comment)."
> I think the opint about the proofreader adding a comment should be more
> prominent i.e. included at the beginning under 'system roles'
> for us,anyway, the role of proofreader will always be to comment, 
> rather
> than to reject out of hand.

Will do.  See the above comment on 'notes'.


> typo? For section 2.4.2, A.4 i think it should read "Pangloss adds
> *language* (if possible)..."

oops... will change that.  cut 'n paste error :)


> Anyway, thanks for the spec & HTH.

No problem.  I'll post an updated spec in a sec.

-Steve



More information about the Pangloss mailing list