[Kde-i18n-pt_br] Migrando

[Fernando Boaglio]

Oi Helio,

Respondendo:

>Primeiro, porque precisa de uma base de dados ?

Com essa base de dados eu controlo quem está mexendo nos pacotes, adiciono
novos pacotes e responsáveis de pacotes facilmente com dois cliques do
mouse.

http://kde-i18n-ptbr.codigolivre.org.br/responsaveis.php

Além disso eu tenho um cadastro de erros de tradução, que assim que
cadastrados enviam emails automaticamente para os admins do projeto (o
Stephen e eu).

http://kde-i18n-ptbr.codigolivre.org.br/bugs.php

Abaixo um email que te enviei quando você teve a mesma dúvida.

Eu sei que parece que eu estou totalmente na contramão, mas o problema é que
é complicado fazer uma migração dessas e perder tudo o que temos.

O próprio site do i18n fez um sisteminha parecido com o meu:

http://i18n.kde.org/team-infos.php?teamcode=pt_BR

Mas o sistema deles é bem mais simples, é apenas um cadastro de voluntários,
não tem o controle de pacotes x usuários que o nosso sistema tem.

[]'s
Fernando Boaglio

---------- Forwarded message ----------
From: Fernando Boaglio <boaglio em gmail.com>
Date: Jan 29, 2006 1:00 AM
Subject: Re: Requisição para integração dos sites
To: Helio Chissini de Castro <helio em kde.org>
Cc: stephen.killing em kdemail.net, thiago em kde.org , gustavo.boiko em kdemail.net


Oi,

Desculpe pelo atraso da resposta.

A parte dinâmica consiste nos pacotes do KDE, dos voluntários e do
relacionamento
pacotes X usuário, além das notícias e dos erros (cadastrados pelo site).


Veja a estrutura do banco:

# phpMyAdmin SQL Dump
# version 2.5.6
# http://www.phpmyadmin.net

#
# Servidor: localhost
# Tempo de Generação: Jan 29, 2006 at 12:59 AM

# Versão do Servidor: 4.0.18
# Versão do PHP: 4.3.11
#
# Banco de Dados : `kde_i18n_ptbr`
#

# --------------------------------------------------------


#
# Estrutura da tabela `erros`

#

CREATE TABLE erros (
  id tinyint(4) NOT NULL auto_increment,
  programa varchar(50) NOT NULL default '',
  descricao text NOT NULL,
  corrigido tinyint(4) NOT NULL default '0',
  PRIMARY KEY  (id)


) TYPE=MyISAM COMMENT='Erros de tradução';

# --------------------------------------------------------

#
# Estrutura da tabela `noticias`
#

CREATE TABLE noticias (
  id mediumint(9) NOT NULL auto_increment,


  data date NOT NULL default '0000-00-00',
  usuario_id mediumint(9) NOT NULL default '0',
  texto text NOT NULL,
  PRIMARY KEY  (id)
) TYPE=MyISAM;

# --------------------------------------------------------



#
# Estrutura da tabela `pacotes`
#

CREATE TABLE pacotes (
  id mediumint(9) NOT NULL auto_increment,
  nome varchar(100) default NULL,
  tipo char(1) NOT NULL default '',
  PRIMARY KEY  (id)


) TYPE=MyISAM;

# --------------------------------------------------------

#
# Estrutura da tabela `pacotes_usuarios`
#

CREATE TABLE pacotes_usuarios (
  pacote_id mediumint(9) NOT NULL default '0',


  usuario_id mediumint(9) NOT NULL default '0'
) TYPE=MyISAM;

# --------------------------------------------------------

#
# Estrutura da tabela `usuarios`
#

CREATE TABLE usuarios (

  id mediumint(9) NOT NULL auto_increment,

  login varchar(50) NOT NULL default '',
  senha varchar(50) NOT NULL default '',
  email varchar(50) default NULL,
  tipo char(1) default NULL,

  nome varchar(50) default NULL,
  PRIMARY KEY  (id)
) TYPE=MyISAM;



 --
[]'s
boaglio em gmail.com



Ok, baseado nestes requisitos eu vou analisar a melhor maneira para
> verificar
> tudo isso. Até mesmo decidir se mudamos para uma infraestrutura melhor que
> o
> twiki.
> As contas e o contato não seriam problema nenhum
>
> Quanto ao banco, quais as partes são dinâmicas ?
> Hoje, mesmo para as notícias não usamos nada mais que o twiki, sendo que
> ele
> tem histórico similar a CVS.
>
> Abração
>
> --
> Helio Chissini de Castro
> KDE Developer
> Brasil/South America Primary Contact
>
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.kde.org/pipermail/kde-i18n-pt_br/attachments/20070102/578545ab/attachment.html